2ヶ月ほどJavaをやった頃、無謀にも機械学習に手を出し始める。本を一冊買って隅々まで読み込んだ。この頃から鬱が寛解し始める。プログラミングに夢中になって、1日12 時間以上はPCの前に座ってひたすらコードを書いていた。不思議と疲れはなかった。ゲーム用に買ったデスクトップ PCにそこそこ良いGPUがついていることが判明したので、Tensorflowでモデルもどきを作り、AI （笑）を組み込んだポートフォリオ用web アプリを3ヶ月かけて作成した。サンプルコードを超える範囲はドキュメントを読む、適宜技術書で知識を補うなどしてなんとかオリジナルと言えるコードをひねり出すこともこの頃覚えたと思う。なお肝心のモデルはチューニングは一切していないわ当然精度も悪いわでその筋の人が見たら鼻で笑うレベルであるが、一人でアプリケーションを作り切ることができたのは大いに自信に繋がった。

・求職活動

ポートフォリオを持って5社ほど受け、うち1社の小さな受託系企業に内定を貰い、無事職にありつくことができた。文系未経験第二新卒を雇う勇気を出してくれた会社には感謝しかない。

・それから、現在

会社規模が小さいからか、個人の裁量が大きく、設計から実装、テストまで何でも任せてもらえた。良き上司に恵まれ、主にUnityやスマホアプリの開発を担当し、技術の奥深さ面白さに触れさせてもらった。自身が実装を担当したアプリが世に出ていくことの喜びみたいなものも味わえた。この会社は昨年度退職し、現在は500人規模の自社開発系企業でiOSアプリエンジニアをやっている。スキルは未熟だし対人恐怖的なものも治ってはいないけど、私はプログラミングが好きで、エンジニアとして骨を埋めたいとか身の程知らずにも思っている。

ご覧の通り、私は幼い頃からプログラミングに触れたりモノづくりをしていたわけではない。むしろ目覚めは遅い方である。そういう人でも興味があるなら、IT エンジニア目指してもいいんじゃないか、そうであってくれ、という気持ちで書いた。読んでくれてありがとう。プログラミングはいいぞ。

Permalink | 記事への反応(6) | 08:47

2021-01-08

■プログラミング学ぶの大変すぎ

初めてプログラミングを学ぶことになったんだけど、正直全然理解が進まなくてしんどい。

・コーディングするのは初めて

・学ぶ言語はJava

・普段は設計書書いたりしていて、ソースを見ることもある

・Javaではない言語だがバグ特定のためにデバッグすることはある

12月半ばから始めたオンラインの動画講座で、初歩的なところから初めてMySQLとかJSP/サーブレットを使って簡単なWEB アプリを作るところをやっている。

解答というか、書かれたコードをみるとなるほどそうやってやればいいのねと思うものの、いざ自分で書こうとすると手が動かない。複合的になるにつれ、こことここで学んだ書き方で書けばいいというのがわからなくなっていくというか…

書き方については見返したりしながら進めているので知識は頭に入っているはずなのに、部分的に？理解していて頭の中で繋がっていないのか。

始めて1ヶ月もたってないので、そんなすぐは書けるようにはならんだろと思うものの、自分で書けなくて結局分からなくて解答見てしまうのが悔しい。でも解答見なかったら先に進めないんだよな。

プログラミング学んでる人、こういう書き方をすればいいんだなってどうやったら思いつくの？経験？

※向いてないというコメントはなしで。趣味ではなく必要なのでやっていて、嫌いになるとモチベが上がらないのでできるだけ前向きにいきたい。

昔数学を始めた時にxとyが出てきて、二次関数くらいから全然解けなくて泣いた時の気持ちに近い。今となってはなんでそこにつまづいてたのかもわからないけど。

Permalink | 記事への反応(3) | 19:31

2021-01-05

■"Web フロントエンド"の悲しみと明るい未来

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 を誰でも簡単に実現するという未来が、もしかしたら今回こそ実現できるかもしれない、と僕は思ってます。

Permalink | 記事への反応(7) | 16:41

2020-10-16

■anond:20201015205510

設計は自分たちでと言うが、設計すらできてない。

特に最近の技術にはまるっきしついていけてないためか、Ajax（今時Ajaxというような単語を出してしまったところがもうあれですが）などの非同期処理が必要なUIに関する設計が未だにJSP ベースのものになっている。

さらに正規化、オブジェクト指向などモデリングに対する知識は皆無で、すべてがただの落書きになっている。

大手 SIerは人を管理することが得意というが、管理すらできてなく押し付けてるだけである。証拠に誰が何をしているのか全く理解をしていないから実際の進捗と客先に報告する進捗の解離が甚だしい。我々からすると嘘の報告を客先にして、その結果客にコレコレと言われてしまったからどうにかして欲しいというような全くプロジェクトの進行とは無関係なことを言い出す始末。

現場からは以上です！

Permalink | 記事への反応(0) | 10:55

2020-09-06

■Java プログラマだけどいい加減JSP+サーブレットじゃなくてSpringで書かせてほしい

色々めんどいから

Permalink | 記事への反応(2) | 21:05

2019-03-26

■5年いた富士通を退職した理由

5年エンジニアとして務めた富士通を一昨年退職した。そろそろほとぼりも冷めたと思うので、書く。

真面目に書いている増田もいるが、僕は自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる。

開発環境がだめ

まずこれがトップにくる。

本当にだめだった。多分開発させる気なんてなかったんだろうなあ。ニートでももうちょっといい環境を使っていると思う。

メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノート PC しか支給されなかった。

Macなんか認めん！iOSアプリも富士通 PCで作れ！（本当にあった話）。

机上環境もだめ

いろんな環境にいたが、その中でもひどかったのは、もともと生産ラインがあった場所に机を置いて事務所として使っていた場所だ。机もせまかったし、気温も暑いか寒いかのどちらかだった。

そこに協力会社を大量に押し込んで、ソフトウェアの生産ラインを作っていたのだった。つまりライン工だね！

椅子もすりきれ、キャスターもついていたらまだいい方みたいな感じだった。自腹で買ってもちこんでいる人もいた。

事務室 環境もだめ

電話会議をみんな四六時中している。

エンジニアが全員ヘッドセットしている異様な光景は、入社時、ここはコールセンターかと思ったほどだ。

だいたい協力会社と進捗会議しているのである。そんなに毎日電話したら、進捗するものも進捗しないだろう。

なので、ここのエンジニアはあまりコーディングをせず、もっぱら進捗管理している。僕はそのなかでもコーディングするレアな人間だったので、うるさくてしょうがなかった。でもイヤホンで音楽聞くのは禁止だった。

上長が君を呼んでいるのが聞こえなかったらどうすんの？だってさ。いや、みんなヘッドセットしてますやん。

評価 制度の納得感がない

評価はプロジェクトの成否にかかわらない。

じゃ、何を評価するのか。よくわからない。

一応目標は書く。達成しても評価低いときもあったし、未達でも昇格するときもあった。

数半期連続で目標達成したのに全然昇格しない時期があって、上司に問うたら、「いや〜、うちは年功序列だからね。。」だってさ。そうすると僕の目標は1年で10年分の年をとることだ。

古い方法へのこだわり

社内にとある開発標準がある。

これに従えばプロジェクトは成功すると信じられている。というよりも、何かがうまくいかなかったときに「なんで開発標準に従わなかったの？」という責められ方をする。たちの悪いISOみたいなものだ。

内容は明らかに古く、ウォーターフォールのシステム開発用にしか使えない。これを無理やりモバイルアプリ開発に適用したり、Webに適用したりする。Webをウォーターフールでつくるもんだから、一度作ったら終わりの作りきりの製品になる。

工程だけでなく、品質についても言及されている。例えば試験項目の品質はいかにバグが検出されたかで測られる。

「試験してバグは1件です！」

「おかしい、もっとバグが出るはずだ！バグが出るまで試験しろ！」

新しい方法・技術の導入の難しさ

開発手法にしてもアジャイルをなかなか実践できなかった。常にウォーターフォールの設計だった。承認フローが差し込めないからね。未だにアジャイルがウォーターフォールに対してどうメリットがあるのか、どう導入するのかを議論して、「なんちゃってアジャイル」（単なる細かいウォーターフォールの実践）を導入してみたりする。

技術に関しても導入は難しかった。クラウドなんて信用できない。他社のしかも、どこにあるかわからない場所になんてデータが保管できるわけがない！

残業 時間の評価

僕のサラリーに一番影響するのは残業時間だった。正直残業しないと生活がしんどかった。

自動化？

ふざけちゃいけない。全て手作業で時間をかけて、丹精込めてビルドするんだ。

バグを埋め込むのもいい方法だ。残業時間が増えてサラリーも増えるし、試験も楽になる！炎上させて鎮火すると、上司の評価もあがるぞ！

スキルと無関係の異動

本人の志向やスキルとはだいたい無関係に異動がきまる。

どう考えてもG Suiteを使えば一発でおわるのに、何番煎じかわからないアプリを作らされる。JSPで。こんなんを作りにきたんだっけ？

社外技術への関心のなさ

僕はまずはGitの啓蒙から始めるのが通例だった。でもこれがまた苦労するんだ。

しかもだいたい信用してくれない。日付が入ったフォルダにgit からコピったファイルをおいて作業している。それ、Git使ってる意味は？？

なんちゃって フレックス

8:50から 12:00がコアタイムのフレックスだった。どうしても連日深夜作業したエンジニアを朝に叩き起こしたいらしい。遅刻にはかなり厳しく、評価にもダイレクトにひびくので、朝忘れ物して5分遅れそうだな、と思うと「体調悪いです」と言って午前休をとることも多かった。そこまでして8:50に出社しても、べつに特別な業務があるわけでもない。

そこまでエンジニアの行動を縛る意味はあるんですかねー。

人が均質的

なんかみんなおんなじに見えてくる。自社の文化に染まってんなって感じの。ほとんど新卒しかいないから、他社の文化なんてのはなかなか入ってこないしね。

みんな真剣なようで真剣でない。悪い意味で真面目。面白い人や尊敬できる人はあまりいなかった。

個人 時間のなさ

人の時間を奪うことに関して悪ではない雰囲気だった。自席にいるとすぐに呼び出されるので、どうしても仕事に集中したい場合は会議室や打ち合わせスペースを予約してそこにノート PCを持ち込むようなハックが必要だった。僕は残業時間に仕事の時間を確保していた。会社にきているのに仕事の時間を確保しないといけないとは。

会議は特に時間泥棒なんだけど、上司が率先してやるもんだから、みんな船漕いじゃってもう。みんなが船こぐような会議は必要？

難しい顔しながら居眠りするのがうまくなった。

未来のほの暗さ

最近45歳以上のリストラがバズっているが、あまり未来が明るい雰囲気の会社でなかった。景気の良い部門もあまり見たことがないし、野心的なプロジェクトもあまりなかった。

個人でみても、特段給与もよくなく、昇進しないかかぎり給与はよくならないし、現状が特に良くなかった。給与サイトを見ると、平均年収は比較的高い方だが、それは残業をした場合である。最近は残業規制も厳しく、あまりもらえないんじゃないかと思う。まあ、最終的には給与だよね。

ちょっと 追記

まさかここまでバズるとは..

消したい衝動に駆られつつもまだ残しておきます。

ここにかいたのは僕の観測範囲です。非常に大きな企業なので、もしかしたら良い環境の部署もあるかもしれません。また、僕がいた時期と今は変わっているかもしれません。

Permalink | 記事への反応(34) | 23:31

2018-11-08

■

まあ

「JavaScriptはJava の子分であり、JavaとJavaScriptを組み合わせたものがJSP である」

とかのアンポンタンな理解でも、動くものは作れるだろう

他の技術者と話が通じないだけで

統失扱いされてたけど、こういう思い込みで独自理解してる人は結構いるんじゃないかな

Permalink | 記事への反応(0) | 11:58

2017-04-13

■[内製][外注][顧問プログラマ][技術顧問][ABテスト][改善][判断基準][システム][会者定離]

management

自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー

会者定離 - Wikipedia
ttps://ja.wikipedia.org/wiki/会者定離

できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
ttp://b.hatena.ne.jp/entry/s/togetter.com/li/1170691

「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
ttp://japan.zdnet.com/article/35058310/

従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine .net/news/20 17 1005-superboss/

「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://techplay.jp/column/366

サイボウズ、離職防止の切り札は「出戻り歓迎」
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://blog.cybozu.io/entry/20 20/02/28/080000

ジョイ・インク (Joy, inc.) のメンローイノベーションズに行ってきた
ttp://kawaguti.hateblo.jp/entry/20 17/08/15/095840

プログラマーは全員ペアを組んで仕事をする
ttps://www.slideshare .net/yattom/ss-79372905

ペアプロ属人化 - Google 検索
ttps://tinyurl.com/y8tkhuhz

1業務に2人を配置して23年連続黒字になった秘密
ttps://bit.ly/2MylBjs

コアコンピタンス・経営判断・技術 ノウハウ・開発スピード・改善・技術 顧問・内製化・比較・判断基準・トレードオフ・ABテスト

ソフトを他人に作らせる日本、自分で作る米国
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784

事業のコアになる部分は、アウトソースしてはいけない。
ttps://medium.com/@kuranuki/aac6062adfb2

アウトソーシングしてるものを強みには出来ない。
ttps://twitter.com/kuranuki/status/225727331925368832

スキルやノウハウが蓄積できる業務はコア業務
ttps://www.noc-net.co.jp/blog/2015/01/column_025/

コア技術の強みは、自社が大切に保持しなければならない。それが、以上に並べた４つの事例からくみとった教訓だ。
ttp://brevis.exblog .jp/26943020/

内製　外注 - Twitter検索

プログラミングとは経営判断の集積である
ソースコードの一行一行は、経営判断そのものだ。
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
（中略）
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。

ソースコードの一行一行が経営判断そのものになる
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683

プログラムは全て決断である。
ttps://bit.ly/2JzCggZ

「ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
ttps://twitter.com/machu/status/25494063962

「モダンな開発環境×技術顧問×内製化」San san×日経電子版アプリ開発の最前線を語る夜

ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。

「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ttp://careerhack.en-japan.com/report/detail/525

ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。

サイバーエージェント藤田社長が語る技術者採用の理由／Ｔｅｃｈ総研
ttps://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=001780

2017年 1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
開発環境も外部のASP サービス利用から内製化に切り変えた。
（中略）
サービスの改善や新サービスの開発時に、ASP サービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttps://thinkit.co.jp/article/12761

システム内製化は、業者に頼むよりずっと難しい
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467

システム内製化度テスト
ttp://d.hatena.ne.jp/forest 1040/20 10 1015/1287109777

システム発注社はSIに発注するより内部で作った方が幸せになれる理由 - Rails Webook
ttp://ruby-rails.hatenadiary.com/entry/20140818/1408287600

「五年あれば、どんな企業でも内製の体制を築ける」
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO

RFP（提案依頼書）

即戦力になるような人材なんて存在しない。
だから育てるんだ。
スティーブ・ジョブズ

ABテスト　デザイン　OR　ボタン　OR　文言 - Twitter検索

B2Cのサイト/アプリを外注して成功している会社ってどこ？
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの？
ttps://twitter.com/fromdusktildawn/status/874796380522336256

「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ

外注はPDCAを回せないという致命的な欠点がある。IT スタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ

銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttp://b.hatena.ne.jp/entry/363456374/comment/Shin-JPN

Joel on Software - ジョエル・テスト
ttps://bit.ly/2vkDd8E

1日1000個のA/Bテストを行う「Booking.com」の開発の裏話を聞いてきました【前編】
ttps://gigazine .net/news/20161002-booking-com-ab-t est/

1日1000個のA/Bテストを行う「Booking.com」の開発の裏話を聞いてきました【後編】
ttps://gigazine .net/news/20161002-booking-com-technology/

正解に当たるまで回し続ける！3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
社員は全員一致で、リッチな方が見やすくて良いと思っているのですが…。
ttps://seleck.cc/165

海外テック情報局：eBayではダサいデザインのほうがコンバージョン率が高かった｜gihyo.jp … 技術評論社
デザイナと口論したいのではなく，見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
あんたがありえないほどキレイだ！とか思ってても，何の役に立つ？
ttp://gihyo.jp/dev/clip/01/tech_information/vol69/0003

ttps://twitter.com/yoppymodel/status/1227445967215120386

選択の科学　２４種類のジャムを売り場に並べたときと、６種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの１０分の1しかなかったのです。
ttps://amzn.to/2I2V1O4

エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由１：変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
トライする回数　×　成功率　＝　成功
という式で、成功率の方をあげることは不可能なので、トライする回数を圧倒的に増やすのが成功の鍵だ、という発想なり。
ttps://chikawatanabe.com/20 10/11/17/technical_founders/

東大合格者ランキングは正しいのか？――常に分母は何かを考えよ
コツは、(2)と(3)の両方の“率”を正確に記録し、両方が上がるようにそれぞれ別の施策を立てることである。
ttp://bizmakoto .jp/makoto/articles/0705/22/news008.html

何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
閾値を越えない限り、やっても意味はないのだと。
ttps://ameblo .jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b

技術 ノウハウがたまる（ノウハウの社内蓄積）

①内製

②内製+技術顧問

技術 ノウハウがたまらない

①顧問プログラマ

②外注

レモン 市場・情報の非対称性

レモン市場 - Wikipedia
ttp://bit.ly/2qQbadu

フラクタルなレモン市場問題｜建築不動産クラスタ交流会の件その１

ttp://realtor-readyabooks.hatena blog.com/entry/20 100515/1273919457

中間業者を中抜きすると受発注者はWin-Winになるか？

ttp://ledsun.hatena blog.com/entry/2016/02/28/014851

ttps://ja.wikipedia.org/wiki/情報の非対称性

ttps://ja.wikipedia.org/wiki/逆選抜

取引 コスト

ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
「交渉コスト」
「監督と強制のコスト」

剰余価値、時給○○○○円、月額○○○万円

時給制（時間を売る）が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
ttps://twitter.com/YamadaQuality/status/955988197976059905

でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96

利益相反・エージェンシー スラック・管理・モニタリング・時間

エージェンシー・スラック（agency slack）とは、エージェントが、プリンシパルの利益のために委任されているにもかかわらず、プリンシパルの利益に反してエージェント自身の利益を優先した行動をとってしまうこと。プリンシパル＝エージェント理論 - Wikipedia

ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/8728 20182883762176

ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120

ttp://getlife.hateblo.jp/entry/2013/09/10/015011

見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
ttp://b.hatena.ne.jp/entry/357516986/comment/netcraft3

プログラマーは皆、常に秘密や嘘を抱えている
納期よりもかなり早い段階で実際には完成しているにも関わらず、
納期ギリギリになるまで「まだできていません」と発言するのだ。
ttp://d.hatena.ne.jp/totopon 114689/20120 111/1326266304

モニタリングコスト（監視費用）
　エージェントが利益相反行動をしていないかどうか監視するためのコスト。

ボンディングコスト（保証費用）
　自身の行動がプリンシバルの利益追求にかなっていることを証明するために
　エージェント自らがかけるコスト。
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292

エージェンシーコストとは
ttp://www.nsspirit-cashf.com/yougo/yougo_agency.html

技術 顧問・内製化・顧問 プログラマー

文系未経験からプログラミングを独学で学び外注してたWebサービスを内製化するために勉強したこと - ゼロイチ起業ノート
ttps://blog.zerotoone.jp/entry/20 17/03/15/065148

Rails　技術顧問
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
顧客企業による内製化を支援する
ttps://www.oiax.co.jp/consulting

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
開発支援
ttps://everyleaf.com/development-support

【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo .jp/2015/10/interview_10/
ttp://cast-er.com/b log/client-interview-masaki-komagata/
内製化に切り替える場合も援助をいたします。
ttp://fjord .jp/commissioned-development/

真の Permalink | 記事への反応(2) | 18:35
ツイートシェア

2017-04-11

■オライリーに出てくるフレンズ

参考：http://www.oreilly.com/animals.csp

サーバル
- Java パフォーマンスチューニング第2版
サバンナシマウマ
- 実践 Rails
カバ
- JavaScript クックブック
アライさん
- Applying RCS and SCCS
フェネック
- Java Servlet and JSP Cookbook
フォッサ
- Hands-On Sencha Touch 2
アクシスジカ
- Fonts and Encodings
キングコブラ
- Larger Cover Dreamweaver in a Nutshell
ミナミコアリクイ
- PDF 構造解説
- Access Database Design and Programming, 3rd
- Access Cookbook, 2nd Edition
クジャク
- XMLクイックリファレンス第2版
- XML デスクトップリファレンス第2版
エリマキトカゲ
- Creating Applications with Mozilla
ジャガー
- Mac OS X 第2版
アルパカ・スリ
- 続・初めてのPerl 改訂第2版
アメリカビーバー
- Essential Microsoft Operations Manager
オグロプレーリードッグ
- JXTA in a Nutshell
ライオン
- Java魂
- Java and XML 第2版
オオアルマジロ
- UNIX システム管理第3版 VOLUME 1
ヘラジカ
- Apacheクックブック第2版
アフリカタテガミヤマアラシ
- C/C++セキュアプログラミングクックブック VOLUME 2
ハシビロコウ
- What's New in Flash Player 11
アフリカオオコノハズク
- DOM Enlightenment
ワシミミズク
- ステートフルJavaScript
マーゲイ
- デザイニング・ウェブナビゲーション
キタキツネ
- Programming Firefox
カピバラ
- C# Database Basics
タイリクオオカミ
- JavaServer Pages 第2版
ヒグマ
- Programming Flash Communication Server
リカオン
- Rails Cookbook
アードウルフ
- Clojure Cookbook

Permalink | 記事への反応(0) | 23:58

2017-03-22

■JINS はマジで やばい

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. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける

クレジットカード番号の送信はクライアントサイドで XHR Level 2 で行ない JINS のサーバーやルーターの通信ログに証拠が残らないようにするとよいだろう

3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す

このようにすることで、クレジットカード情報を収集していたという事実を関係各位に認識させる時間を可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実はバカなスクリプトキディが適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。

こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処も必要ではないか。

JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータや資産を防護する基本的な姿勢が欠けているとしか思えない。

Permalink | 記事への反応(0) | 16:07

2016-05-22

■http://anond.hatelabo.jp/20160521235357

元増田です。トラバありがとう。

世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜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騒動とかもあったように、なんかまだちょっと不安がある感じがします。偏見でしょうかね。。

Permalink | 記事への反応(1) | 00:35

2015-02-11

■SpringBootアプリをjavafxを使って配布しやすくしよう

概要

Javaで開発されたアプリケーションにはインストールにまつわる難点がある。

それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。

また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。

javafxで導入されたパッケージャを用いることで各OS ネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。

SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。

問題点の整理

Javaで開発されたアプリケーションの配布には以下の問題点がある。

jreのインストールが必要
- 30億のデバイスで動こうがそれはjreをインストールした後の話。
- .netのランタイムのインストールすら面倒で敬遠されるのにOracleとか無理やろ。
- 自動インストールさせるのも面倒。野良リポジトリ URLを追加したりOracle からのダウンロード自動化したり。
起動の仕方があまり標準的でない
- 一般人にとってアプリケーションの起動とは application.exe や application を実行するもの。
- application.bat や application.sh とかいい加減にしろ！
- java -jar application.jar とか本当にユーザーに起動させる気あんのか！
プロセス名がすべてjava
- 負荷監視時のプロセスの特定が面倒
- 運用時、killする対象のプロセス取り違えなどのリスクがある
- だから java という文字列をユーザーに見せるな！！
複数バージョンのjreをアプリ毎に切り替えないといけない場合は更に煩雑に
- JAVA_HOMEを書き換える？alternatives --config java？
- そんな複雑なことできるか！馬鹿にすんな！！
パッケージングに関する情報や知見に乏しい
- ドキュメントは英語だったり曖昧だったりで開発者の意欲を削ぐ。
- java web start とかコード署名とか、本当にもうお疲れ様です。意味わからん。
インストーラーじゃない
- application.tar.gz とか application .zip とか
- まぁ個人的にはこっちのほうが好きだけど

解決方法として

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 )を確認するとちゃんと開発は続いている。

実際にどのようにすればパッケージングできるか

まずアプリケーションを maven アプリとして開発する。

pom.xml に以下を追加する。

mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。

vendor は適当に組織や個人の名前を入れておきましょう。

※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805

&lt;plugin&gt;
  &lt;groupId&gt;com.zenjava&lt;/groupId&gt;
  &lt;artifactId&gt;javafx-maven-plugin&lt;/artifactId&gt;
  &lt;version&gt;8.1.2&lt;/version&gt;
  &lt;configuration&gt;
    &lt;mainClass&gt;[main method class]&lt;/mainClass&gt;
    &lt;vendor&gt;[Vendor Name]&lt;/vendor&gt;
  &lt;/configuration&gt;
&lt;/plugin&gt;

あとはそのままビルドすればよい。

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などはまだ未検証です）

課題

インストーラーで含めることのできる実行環境は jre なので jdk が必要とされるアプリは実行できない
- 問題になるのは jsp 。jsp のコンパイルに javac が必要なので。
- 切り捨てるのが一番だとは思いますが。
サーバー系のアプリの場合は init script を用意しなければいけない
- 今後の検討課題ですね。