  |
はてなキーワード: JSPとは
そっちももう売ってるものばかりだよ。一般への普及はこれからだけど。
スパムメールに騙されて、スパム文面（下記参照）の「振込入金の詳細については、SMBCダイレクトでご確認いただけます。」のURLリンクを踏んでしまいました。
だけど、それは謂わばスパム側による囮の様なURLで、三井住友銀行のドメインだったので、幸運にも今回は難を逃れることができました。
今回のスパム側の主な目的は、メール受診者（スパム被害者）がHTML形式でメールを確認して、また、メールの内容を信頼して「ご確認」のURLリンク「ttps://www.shuhmsドットcom」（詐欺サイト）をクリックすることだと思われます。
私は普段から平文形式でメールを確認するので、（実際の被害を受けるという意味では）今回難を逃れたけど、普段からHTML形式でメールを確認していたり、情報弱者や高齢者だったら騙されやすいだろうと感じます。
ポイントは、「ご確認」のリンク先が「ttps://www.shuhmsドットcom」になっていた他、「振込入金の詳細については、SMBCダイレクトでご確認いただけます。」の次の行のURLの/kojin以下の文字列がオリジナルと違うことです。
それ以外、題名、送信元、メール内容についてオリジナルに擬態しています。
普段からスパムメールに注意していますが、スパムの擬態が高度化して、情報弱者が騙されやするなる閾値を超えたと感じたので、警鐘の意味を込めて書いておきます。
【スパムメール】
-------------------------------------------------------------------------
Subject: 【三井住友銀行】振込入金失敗のお知らせ
Date: Thu, 9 Mar 2023 **:**:** +0800
From: 三井住友銀行 <SMBC_service@dn.smbc.co.jp>
-------------------------------------------------------------------------
-------------------------------------------------------------------------
Date: Sat, 25 Feb 2023 **:**:** +0900
From: 三井住友銀行 <SMBC_service@dn.smbc.co.jp>
Reply-To: SMBC.Auto.reply@ar.smbc.co.jp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
三井住友銀行より、ご指定口座への振込入金失敗についてお知らせします。
振込入金の詳細については、SMBCダイレクトでご確認いただけます。
ttps://www.smbc.co.jp/kojin/app/smbcapp.html?aff=dirct_mlODM1902001（←kojin以下の文字列がオリジナルと違う）
―――――――――――――――――――――
※振込依頼人から振込の「取消」「変更」「組戻」があった場合等、お知らせした明細と実際の手続が異なる場合があ
ります。
※本メールは、お客さまお届けのメールアドレスへお送りしています（本メールの再送依頼は受け付けておりません）
。
偽のメール等で誘導された当行を装う偽サイトに、お客さまの口座情報やワンタイムパスワード等を入力すると、不正
＞ ttps://www.smbc.co.jp/kojin/special/stop_phishing_crime/
「三井住友銀行」名でお送りするメールには、携帯キャリアのメールアドレス宛を除き全て電子署名を付けています。
＞ ttps://www.smbc.co.jp/security/smime/
閲覧しているサイトが当行の正当なサイトかどうかを、電子証明書により確認いただけます。
＞ ttps://qa.smbc.co.jp/faq/show/297?site_domain=default
本メールに対するメールでのご返信・お問い合わせはお受けしておりません。メールの内容に身に覚えがない場合や、
サービス等についてくわしく知りたい場合は、当行ホームページをご覧いただくか、以下より電話番号を確認の上、お
問い合わせください。
＞ ttps://www.smbc.co.jp/contact_list.html
＞ ttps://direct.smbc.co.jp/aib/aibgsjsw5001.jsp?sc=081
-----------------------------------------------------------------------
-------------------------------------------------------------------------
駄文なので最初にまとめておくと、知識ゼロ異業種から転職して何とかエンジニアとしての人生を始めました、という話。経歴がショボすぎて誰かの道標にすらならないだろうけど書き残しておく。実名で書く勇気はないので増田にて失礼。
PCを初めて触ったのは4歳の頃。
黒くてごついボディが幼心にぐっときたのを覚えている。この記憶があったためか、初めて自分で購入したPCはThinkPadだった。
我が家にインターネット開通。深夜に親が寝てからこっそり2chとニコニコ動画を見ていた。PS2でドラクエ8をやってグラフィックに感動する。まだプログラミングという言葉は知らない。母親のヒステリーと父親の拳骨に耐える日々だった。
地元の高校に進学。友人とﾎﾑﾍﾟ(死語)を作成。html/CSSで文字の色か変えられたりアニメーションをつけられることに気付く。この頃もまだプログラミングに目覚めない。プログラム？理系の人がやるお仕事なんでしょ？という雑な認識であった。
もちろん文系学部に進学。人の視線が怖かったので前を向いて歩けず会話もままならなかったが、制服が可愛いという理由だけでお洒落カフェでバイトを始める。私は阿呆だが、この阿呆さないしは無鉄砲さでエンジニアになったと言っても過言ではない。
新卒入社した会社を3ヶ月で退職。支えてくれる彼くんとかもいなかったので実家でお通夜してた。鬱も発症して薬漬けになった。対面で人と話すことが難しいため、テキストベースで仕事ができる職を探し始める。ここでやっとプログラミングに出会う。
何にせよ無職だから時間は腐るほどある。ヨドバシでカモ丸出しの顔をしてThinkPadを買い、Javaで簡単なアルゴリズムを実装することから始めた。フィボナッチ数列を生成するとかクイックソートを実装するとか。あと5日ぐらいかけてServlet/JSPとMySQLでTODOリストを作った。
2ヶ月ほどJavaをやった頃、無謀にも機械学習に手を出し始める。本を一冊買って隅々まで読み込んだ。この頃から鬱が寛解し始める。プログラミングに夢中になって、1日12時間以上はPCの前に座ってひたすらコードを書いていた。不思議と疲れはなかった。ゲーム用に買ったデスクトップPCにそこそこ良いGPUがついていることが判明したので、Tensorflowでモデルもどきを作り、AI（笑）を組み込んだポートフォリオ用webアプリを3ヶ月かけて作成した。サンプルコードを超える範囲はドキュメントを読む、適宜技術書で知識を補うなどしてなんとかオリジナルと言えるコードをひねり出すこともこの頃覚えたと思う。なお肝心のモデルはチューニングは一切していないわ当然精度も悪いわでその筋の人が見たら鼻で笑うレベルであるが、一人でアプリケーションを作り切ることができたのは大いに自信に繋がった。
ポートフォリオを持って5社ほど受け、うち1社の小さな受託系企業に内定を貰い、無事職にありつくことができた。文系未経験第二新卒を雇う勇気を出してくれた会社には感謝しかない。
会社規模が小さいからか、個人の裁量が大きく、設計から実装、テストまで何でも任せてもらえた。良き上司に恵まれ、主にUnityやスマホアプリの開発を担当し、技術の奥深さ面白さに触れさせてもらった。自身が実装を担当したアプリが世に出ていくことの喜びみたいなものも味わえた。この会社は昨年度退職し、現在は500人規模の自社開発系企業でiOSアプリエンジニアをやっている。スキルは未熟だし対人恐怖的なものも治ってはいないけど、私はプログラミングが好きで、エンジニアとして骨を埋めたいとか身の程知らずにも思っている。
ご覧の通り、私は幼い頃からプログラミングに触れたりモノづくりをしていたわけではない。むしろ目覚めは遅い方である。そういう人でも興味があるなら、ITエンジニア目指してもいいんじゃないか、そうであってくれ、という気持ちで書いた。読んでくれてありがとう。プログラミングはいいぞ。
初めてプログラミングを学ぶことになったんだけど、正直全然理解が進まなくてしんどい。
・コーディングするのは初めて
・Javaではない言語だがバグ特定のためにデバッグすることはある
12月半ばから始めたオンラインの動画講座で、初歩的なところから初めてMySQLとかJSP/サーブレットを使って簡単なWEBアプリを作るところをやっている。
解答というか、書かれたコードをみるとなるほどそうやってやればいいのねと思うものの、いざ自分で書こうとすると手が動かない。複合的になるにつれ、こことここで学んだ書き方で書けばいいというのがわからなくなっていくというか…
書き方については見返したりしながら進めているので知識は頭に入っているはずなのに、部分的に？理解していて頭の中で繋がっていないのか。
始めて1ヶ月もたってないので、そんなすぐは書けるようにはならんだろと思うものの、自分で書けなくて結局分からなくて解答見てしまうのが悔しい。でも解答見なかったら先に進めないんだよな。
プログラミング学んでる人、こういう書き方をすればいいんだなってどうやったら思いつくの？経験？
※向いてないというコメントはなしで。趣味ではなく必要なのでやっていて、嫌いになるとモチベが上がらないのでできるだけ前向きにいきたい。
昔数学を始めた時にxとyが出てきて、二次関数くらいから全然解けなくて泣いた時の気持ちに近い。今となってはなんでそこにつまづいてたのかもわからないけど。
next.js が vercel を提供して CDN からサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。
それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。「とにかくフロントエンド領域しか絶対にやりたくない」という人が沢山いるが、しかし一方フロントエンドで無理しないでサーバーを書くだけで楽になるようなタスクはいくらでもある(典型的には API たくさんアクセスするとか)。
そうしたときに、フロントエンドメインだがバックエンドも書けるみたいな人がそういうサーバー忌避患者を介護する層として BFF の需要があり(無論それだけが BFF に求められるのではなく認証などの要素も大きいが)、サーバーサイドレンダリングというタスクもあるため node.js で何らかのサーバーが書かれていった。
アイソモーフィックな JS によりフロントエンドとサーバーサイドを統合する、という試みはこれまであまり成功しなかったので(結局どっちにも詳しくないといけないから正しく書ける人がすくない)、 next.js の getStaticProps や React Server Component は「サーバーサイドだけで動くコードを見た目上フロントエンドのコードの中に含める」という解決策を提示した。
ここまでしないとフロントの人がサーバー側を書いてくれないという現実は、あるわけですよ。「そんな奴言って聞かせりゃいいじゃねえか」とか思うかもしれないけど、これが現実。これが全てという話でもないけど、わりとこんな話が大きいように僕には見える。
起きていることはそういう話なのだけど、これはけして JSP 時代への先祖帰りではなく、この進歩の先にはサーバーとクライアントを跨いで快適な UX を誰でも簡単に実現するという未来が、もしかしたら今回こそ実現できるかもしれない、と僕は思ってます。
特に最近の技術にはまるっきしついていけてないためか、Ajax（今時Ajaxというような単語を出してしまったところがもうあれですが）などの非同期処理が必要なUIに関する設計が未だにJSPベースのものになっている。
さらに正規化、オブジェクト指向などモデリングに対する知識は皆無で、すべてがただの落書きになっている。
大手SIerは人を管理することが得意というが、管理すらできてなく押し付けてるだけである。証拠に誰が何をしているのか全く理解をしていないから実際の進捗と客先に報告する進捗の解離が甚だしい。我々からすると嘘の報告を客先にして、その結果客にコレコレと言われてしまったからどうにかして欲しいというような全くプロジェクトの進行とは無関係なことを言い出す始末。
5年エンジニアとして務めた富士通を一昨年退職した。そろそろほとぼりも冷めたと思うので、書く。
真面目に書いている増田もいるが、僕は自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる。
まずこれがトップにくる。
本当にだめだった。多分開発させる気なんてなかったんだろうなあ。ニートでももうちょっといい環境を使っていると思う。
メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。
Macなんか認めん！iOSアプリも富士通PCで作れ！（本当にあった話）。
いろんな環境にいたが、その中でもひどかったのは、もともと生産ラインがあった場所に机を置いて事務所として使っていた場所だ。机もせまかったし、気温も暑いか寒いかのどちらかだった。
そこに協力会社を大量に押し込んで、ソフトウェアの生産ラインを作っていたのだった。つまりライン工だね！
椅子もすりきれ、キャスターもついていたらまだいい方みたいな感じだった。自腹で買ってもちこんでいる人もいた。
エンジニアが全員ヘッドセットしている異様な光景は、入社時、ここはコールセンターかと思ったほどだ。
だいたい協力会社と進捗会議しているのである。そんなに毎日電話したら、進捗するものも進捗しないだろう。
なので、ここのエンジニアはあまりコーディングをせず、もっぱら進捗管理している。僕はそのなかでもコーディングするレアな人間だったので、うるさくてしょうがなかった。でもイヤホンで音楽聞くのは禁止だった。
上長が君を呼んでいるのが聞こえなかったらどうすんの？だってさ。いや、みんなヘッドセットしてますやん。
一応目標は書く。達成しても評価低いときもあったし、未達でも昇格するときもあった。
数半期連続で目標達成したのに全然昇格しない時期があって、上司に問うたら、「いや〜、うちは年功序列だからね。。」だってさ。そうすると僕の目標は1年で10年分の年をとることだ。
社内にとある開発標準がある。
これに従えばプロジェクトは成功すると信じられている。というよりも、何かがうまくいかなかったときに「なんで開発標準に従わなかったの？」という責められ方をする。たちの悪いISOみたいなものだ。
内容は明らかに古く、ウォーターフォールのシステム開発用にしか使えない。これを無理やりモバイルアプリ開発に適用したり、Webに適用したりする。Webをウォーターフールでつくるもんだから、一度作ったら終わりの作りきりの製品になる。
工程だけでなく、品質についても言及されている。例えば試験項目の品質はいかにバグが検出されたかで測られる。
「おかしい、もっとバグが出るはずだ！バグが出るまで試験しろ！」
開発手法にしてもアジャイルをなかなか実践できなかった。常にウォーターフォールの設計だった。承認フローが差し込めないからね。未だにアジャイルがウォーターフォールに対してどうメリットがあるのか、どう導入するのかを議論して、「なんちゃってアジャイル」（単なる細かいウォーターフォールの実践）を導入してみたりする。
技術に関しても導入は難しかった。クラウドなんて信用できない。他社のしかも、どこにあるかわからない場所になんてデータが保管できるわけがない！
僕のサラリーに一番影響するのは残業時間だった。正直残業しないと生活がしんどかった。
自動化？
ふざけちゃいけない。全て手作業で時間をかけて、丹精込めてビルドするんだ。
バグを埋め込むのもいい方法だ。残業時間が増えてサラリーも増えるし、試験も楽になる！炎上させて鎮火すると、上司の評価もあがるぞ！
どう考えてもG Suiteを使えば一発でおわるのに、何番煎じかわからないアプリを作らされる。JSPで。こんなんを作りにきたんだっけ？
僕はまずはGitの啓蒙から始めるのが通例だった。でもこれがまた苦労するんだ。
しかもだいたい信用してくれない。日付が入ったフォルダにgitからコピったファイルをおいて作業している。それ、Git使ってる意味は？？
8:50から12:00がコアタイムのフレックスだった。どうしても連日深夜作業したエンジニアを朝に叩き起こしたいらしい。遅刻にはかなり厳しく、評価にもダイレクトにひびくので、朝忘れ物して5分遅れそうだな、と思うと「体調悪いです」と言って午前休をとることも多かった。そこまでして8:50に出社しても、べつに特別な業務があるわけでもない。
なんかみんなおんなじに見えてくる。自社の文化に染まってんなって感じの。ほとんど新卒しかいないから、他社の文化なんてのはなかなか入ってこないしね。
みんな真剣なようで真剣でない。悪い意味で真面目。面白い人や尊敬できる人はあまりいなかった。
人の時間を奪うことに関して悪ではない雰囲気だった。自席にいるとすぐに呼び出されるので、どうしても仕事に集中したい場合は会議室や打ち合わせスペースを予約してそこにノートPCを持ち込むようなハックが必要だった。僕は残業時間に仕事の時間を確保していた。会社にきているのに仕事の時間を確保しないといけないとは。
会議は特に時間泥棒なんだけど、上司が率先してやるもんだから、みんな船漕いじゃってもう。みんなが船こぐような会議は必要？
難しい顔しながら居眠りするのがうまくなった。
最近45歳以上のリストラがバズっているが、あまり未来が明るい雰囲気の会社でなかった。景気の良い部門もあまり見たことがないし、野心的なプロジェクトもあまりなかった。
個人でみても、特段給与もよくなく、昇進しないかかぎり給与はよくならないし、現状が特に良くなかった。給与サイトを見ると、平均年収は比較的高い方だが、それは残業をした場合である。最近は残業規制も厳しく、あまりもらえないんじゃないかと思う。まあ、最終的には給与だよね。
ここにかいたのは僕の観測範囲です。非常に大きな企業なので、もしかしたら良い環境の部署もあるかもしれません。また、僕がいた時期と今は変わっているかもしれません。
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/
「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://s.nikkei.com/2vJsvYx
優れたマネージャーは自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う
ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html
人材は会社の資産として残らないが仕組みは会社の資産として永遠に残る
ttps://www.amazon.co.jp/dp/B010JM64M6/
ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000
ttps://www.slideshare.net/yattom/ss-79372905
ttps://tinyurl.com/y8tkhuhz
ttps://bit.ly/2MylBjs
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784
ttps://medium.com/@kuranuki/aac6062adfb2
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
（中略）
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683
ttps://bit.ly/2JzCggZ
「ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
「モダンな開発環境×技術顧問×内製化」Sansan×日経電子版 アプリ開発の最前線を語る夜
ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。
「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。
2017年1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
（中略）
サービスの改善や新サービスの開発時に、ASPサービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO
だから育てるんだ。
ABテスト デザイン OR ボタン OR 文言 - Twitter検索
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの？
ttps://twitter.com/fromdusktildawn/status/874796380522336256
「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ
外注はPDCAを回せないという致命的な欠点がある。ITスタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ
銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttps://bit.ly/2vkDd8E
正解に当たるまで回し続ける！3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
海外テック情報局：eBayではダサいデザインのほうがコンバージョン率が高かった｜gihyo.jp … 技術評論社
デザイナと口論したいのではなく，見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
選択の科学 ２４種類のジャムを売り場に並べたときと、６種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの１０分の1しかなかったのです。
ttps://amzn.to/2I2V1O4
エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由１：変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
東大合格者ランキングは正しいのか？――常に分母は何かを考えよ
何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
ttps://ameblo.jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b
①内製
②外注
フラクタルなレモン市場問題｜建築不動産クラスタ交流会の件その１
ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457
ttp://ledsun.hatenablog.com/entry/2016/02/28/014851
ttps://ja.wikipedia.org/wiki/情報の非対称性
ttps://ja.wikipedia.org/wiki/逆選抜
ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
時給制（時間を売る）が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120
ttp://getlife.hateblo.jp/entry/2013/09/10/015011
見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
納期よりもかなり早い段階で実際には完成しているにも関わらず、
エージェントが利益相反行動をしていないかどうか監視するためのコスト。
自身の行動がプリンシバルの利益追求にかなっていることを証明するために
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292
ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F
「顧問プログラマ」再考 - Rails 雑感 - Ruby on Rails with OIAX
ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html
ITエンジニア採用に欠かせない原則とは (1/5)：IT人材ラボ
ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856
ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1
【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo.jp/2015/10/interview_10/
参考：http://www.oreilly.com/animals.csp
https://twitter.com/piyokango/status/844361226767380481
http://www.freezepage.com/1490165400GAZZVSXBDT
である。キャッシュの freezepage ですまんが、まあいいだろ。
これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題は JINS の対応だ。
t_jins_gmo_brandtoken_cancel_if_rireki
t_jins_gmo_brandtoken_change_if_rireki
t_jins_gmo_brandtoken_entry_if_rireki
t_jins_gmo_brandtoken_exec_if_rireki
などといったテーブル名から、おそらく GMO ペイメントトークン決済を利用しているものと思われる。これはクレジットカード番号を一切 JINS 側のサーバーに通過させなくていいような構成になっており、今回のこの事例から JINS 側が保存していたクレジットカード情報が流出した可能性は、恐らくない。
しかしながら今回攻撃されたドメイン https://www.jins.com/ にはクレジットカードの入力ページが存在している( http://s.ssig33.com/gyazo/d09c0f5915f84eab8c8712eb0d23150d )。
この為、こうしたページも不正に改造されていた場合、攻撃を受けていた期間に入力されていたクレジットカード番号が不正に流出している可能性がある。
ところで JINS 側はこうした問題を認識して今朝未明にメンテナンスを行なっていたようである( https://www.jins.com/jp/news/2017/03/322.html )。
推測するに、調査をしたところクレジットカード番号入力ページの jsp なりなんなりが改竄されていた事実はとりあえず確認できなかったので、特になんの発表もしていないのであろう。ところで JINS は 4 年前にもサイトをクラックされクレジットカード番号を流出させた経験がある( https://www.jins.com/jp/illegal-access/info.pdf )。にも関わらずこの対応はちょっとおざなりすぎではないだろうか。
現実に可能性は低いと思うが、例えば以下のような可能性が考えられる。
1. ハセカラ関係者っぽく見せかけた低レベルのクラック ↑ を行なう。
2. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける
3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す
このようにすることで、クレジットカード情報を収集していたという事実を関係各位に認識させる時間を可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実はバカなスクリプトキディが適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。
こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処も必要ではないか。
JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータや資産を防護する基本的な姿勢が欠けているとしか思えない。
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
ユーザー体験がどうかはまあ意見が別れるでしょうからおいておくとして、ずっと楽に開発というのがよくわからないです。普通になんでもいいですけど、ウェブ側のフレームワークでちゃんとしたものを使っていれば別になんでもないことだと思うんですが、具体的にどういう状況を考えられていますか？
プログラムはユーザーサイドだけでは完結しなくて、入力チェックとかいろいろは絶対にやらないといけないですよね。ということで同じロジックを複数書く場面が出てくることが多いと思います。そういう手間も含めたうえで開発が楽になるというのはちょっとよくわからないです。
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？
ちょっとここ書き方分かりづらかったかもですが、「ES6で書く以上はES6を使えばいいじゃん」「変な独自拡張を入れてまでJSを使い続ける理由がわからん」という２つの疑問を同時に書いたつもりです。
将来長持ちする気がしています。
PHPやJSP,ASPが通ってきた道に見えてなりません（まあASPはまだ現役ですか。）。
正直その他のアプリケーション(サーバーサイドや、例えばAndroid/iOS開発)でこのような書き方はまずしないので、なぜわざわざ同一ファイルに書きたがるのかがわかりません。（ロードのコストを嫌がっているとかですかね？）
テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
ええと、テンプレートストリングではなくて、mustacheみたいに十分枯れているテンプレートエンジンでもいいですが、必要かどうかは別として確かに機能の豊富さはどうかはちょっとわかりません。
速度に関しては、実際みんな早いと言っていますがこの手の速度神話はJSにかぎらず昔からちゃんと前提と状況を考えなくてはいけなくて、（例えばJavaは重い！とか関数呼び出しはオーバーヘッド！とか仮想関数は使うな！とか）例えばさっとぐぐるとこんなものが出てきました。
http://www.stefankrause.net/wp/?p=283
まあよくわかりませんが、結局あんまいじらないのが一番良いという当たり障りない結論になってしまいませんか？（あと原理的に生のDOMを操作するのよりも早くなりようがない気がするんですがどうなんですかね？？）
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
ごめんなさい、Reactまわりのエコシステム全体も含めた時を意味したかったです。leftpad騒動とかもあったように、なんかまだちょっと不安がある感じがします。偏見でしょうかね。。
Javaで開発されたアプリケーションにはインストールにまつわる難点がある。
それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。
また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。
javafxで導入されたパッケージャを用いることで各OSネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。
SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。
Javaで開発されたアプリケーションの配布には以下の問題点がある。
javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。
javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。
Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。
公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。
pom.xml に以下を追加する。
mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。
vendor は適当に組織や個人の名前を入れておきましょう。
※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805
<plugin> <groupId>com.zenjava</groupId> <artifactId>javafx-maven-plugin</artifactId> <version>8.1.2</version> <configuration> <mainClass>[main method class]</mainClass> <vendor>[Vendor Name]</vendor> </configuration> </plugin>
あとはそのままビルドすればよい。
maven clean jfx:native
ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。
本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。
これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。
/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。
app の下にはビルドした jar ファイルや依存ライブラリが置かれています。
runtime の下には実行用の jre が配備されています。
実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です）
勝手に登録されるし、しかもメール配信停止退会申請に応じないようなので晒しておきますね
(追記：1月中旬：なんと0369131611に電話をかけても留守番電話にもならずに切られたぞ)
(追記：同日：なんと電話の呼び出し音がなったと思ったら、なにも言わないで退会処理されたぞ→おかけになった電話をお呼びしましたがお出になりません）
http://c-ecil.com/user.app?cmd=fwd&jsp=tokutei&asp=&uid=null&own_id=null
（今回はたぶん全部テキストなのでコピペできるし読み上げられる）
■所在地
東京都練馬区下石神井1丁目7番1シャトーエスポワール103号
■電話番号
03-6913-1611（平日10:00～18:00受付）
support@c-ecil.com
長野康英
■役務内容
■対価の対価
一括メールを送信 500pt
メールアドレスを教える 500pt
プロフィール変更 250pt
1pt=10円
■対価の支払方法
請求金額は申し込み金額とは約一割程度異なる場合がございます。
請求確定金額はご利用カード発行会社までお問い合わせください。
■役務の支払時期
ポイント購入時。
■商品引渡
入金確認後即
サービス提供形態の特性上、役務提供後の返金には応じられません。
お客さんと話してきた内容を人ごとのように聞いているのだが、
先日拾ったフルスタックエンジニアと何となく繋がったところがあったので
暇つぶしに書いとく。
DBの不備と拾いきれないぬるぽで正常系すら落ちまくるシステムへの不満と
画面の統一感がチグハグで分かりづらいという二点で、
そんなシステムをこの人数の規模(想定より遥かに多かったらしいw)でやられてたんですか？と
いう言葉までいただいてきた。
当然だよねーと思う。仕様書も統一されてなくて、画面のデザインガイドラインも一読しないまま
各工程で30%ずつ人員を入れ替えながら突き進んでしまったそうだから。
そのしわ寄せがプロジェクト後半になって鎮火のために投入された自分のようなところに来る訳で、
チームで古参と思われる人に画面仕様について片端から聞いても見事なたらい回し。
入力項目の不備について指摘したら、それjQueryのライブラリの仕様だから中に手を入れてまで直そうか
今の状況では微妙って回答を貰った後で、客先から同じ指摘→再テストの依頼が来たときはいらっとしたわ。
なんでこーんなことになってるんだろうって外野の目で見てると、分業しすぎたんだろうとは思う。
皆、JSPだったり、javascriptだったり、SQLだったり、どれか一つの言語しか出来ない感じで
フロントエンドすら、Ajaxとそれ以外(よくわかんないんだけどさ)で、二チームに別れてる感じ。
要するに、自分含めてスキルがしょぼいんだけど、そりゃ、画面のデザインもチグハグになるよねーっと思った。
フルスタックエンジニアのような、全てわかる器用貧乏で、でもチームリーダーとして仕切れるような人格者が
一人いれば、この状況はもっと違ってきたのかな、なんて。
フルスタックエンジニアがたくさんいれば、こんな分業制でわけわからない開発規模まで膨らんだプロジェクトの人数も
減らせたのかなぁ、なんて。
仕様の共通理解やそのためのツール(仕様書ね)に割くための工数もより少なくてすむわけで。
確かに、人数減らせばその分仕事も増加してブラック間違いなしなんだけど、
この状況を見ていたら、一つよりは二つ、二つよりは三つを持ったゼネラリスト的なスペシャリストがいらっしゃったら、
変われたのかもね。
社内向けのポータルサイトが数年前から稼働しているのだけれども、これが酷いできでソースを見るだけで頭が痛くなる。（サーブレットだよ）
staticおじさんプログラミングのすべてがそこに詰まっているデザイン、かつクラスをコピペして機能拡張をするというまあ良く有りがちな糞コードアプリだ。
まあ、そりゃいいけれど
なんかバージョンアップしようとすると、変なオッサンが自分がデザインして稼働させたシステムを変更させたくない圧力をかけてくる。
なんか、これが自慢のシステムらしい。
HTMLは古い書き方なのは仕方ないにしても、内部のJavaソースがより酷くて
アクセスカウンターのような仕組みがあるんだけれども、アクセス数はアクセスがあったときにたされるのだけれども
その数字をJSPに渡す時に、なぜかint[6] の配列で返してくる。
お尻が切れて表示されるというアクセス数が全くわからないシステムになっている。
ついでに不必要なスレッド処理があるのだけれども、同期処理が不十分で、何回かに一回例外が発生する…
じゃあ、最後までお前が面倒見ろと…
まあやってくれないだろうから、外見からは分からないようにこっそりバグは治しているけれど
なんか馬鹿らしい。
まあ、社内向けだし…
これは規模じゃなくて難易度の話だろ
難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか？
javaだとなんだ、、、オブジェクト指向なコード書けることか？
元増田に話しとくとjavaで開発するにもHadoop、strutsやらのフレームワークや
jspなどなど色々ある
Androidアプリはその中じゃそんなに難しい部類ではないと思う
別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ
別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないから
引き返したほうがいいな
似たように苦しむ事が多いが腹をくくってる
この日記はhttp://anond.hatelabo.jp/20110502041801へのトラックバックです。
jQueryでドラクエ画面作成の記事、楽しく読ませていただきました。
jQueryを使うとAjaxなページが簡単に作れるのですね~。
ドラクエの戦闘画面はシンプルながら洗練されていて優れたデザインだと思いますがそれをWebページに生かそうとしたその発想がすごいと思いました。
ドラクエのストーリーを追うことができるアプリケーションなら私はドラクエ4のゲームブックを遊ぶことのできるWebアプリをJSPで作りました。
Webアプリでは、ゲームブックをやるのに自分でフラグチェックや次のパラグラフをページをめくって探すことをしないで済むようにしました。
id:kwatchが自身のブログで、ベンチマークも取らずして以下のように言ったことに対して、id:uncorrelatedが問題を指摘している。
当然、JSPに対しても実証結果を求められるわけですが、id:kwatch氏は「ベンチマークすれば分かります」と述べるのみで、残念ながら明確な根拠は提示していません。
Javaは良く知らないし真偽は分からないが、その後のid:kwatchのコメントに噴いた。
ベンチマークを取らないでJSPが遅いと主張しているid:kwatchが問題だと指摘されているのに、id:kwatchはid:uncorrelatedにベンチマークを取れと言っている。id:kwatchは、主張者に立証責任があることを知らないのであろう。
id:kwatchは、JSPが遅い理由をJava屋さんはまるでわかってないらしいとか、「相手が嫌い」っつー感情が言動の起点になってるんだから、議論の相手になるわけがないとか、何か問題点を指摘されるたびにブログで吠え面かいているので、悔しくて仕方が無い性質なのだろうな。
