Node.jsのスーパープログラマ達の今 - @ledsun blog
僕がNode.jsを熱心に勉強していた頃に、スーパープログラマとして憧れていた人たちが、今何をやっているのか調べてみました。 github.com Express.jsなんかを作っていたtjは、Go言語がメインに書いているようです。 OSS活動自体あまりやっていなさそうです。 github.com Browserifyをつくっていたsubstackは、主にrustを書いているようです。 サーバーを書いていた人はGo言語に、CLIを書いていた人がrustに行くのかもしれません。 github.com Babelを書いていたsebmckもrustです。 github.com Rad VaggはGo言語とPythonのようです。 github.com tjfontaineはOSS活動がほとんど無くなっています。 ここからはNode.jsを去っていない人たちです。 github.com Guill
実行するたびに決まった順番で値を返すRubyスクリプトはなぜか自分を書き換える - @ledsun blog
Webアプリケーションのテストに使う端末を決定するために、最初はruby -e 'p %w(iPad Firefox Android).sample'とランダムで値を返していました。 使っていると、ランダムよりは順番がよいと感じました。 また、順番も前回使った端末を覚えていて、その次から実行できると嬉しいです。 そして作ったのが、このスクリプトです。 script = File.read(__FILE__).split("__END__\n").first value = DATA.gets puts value File.open(__FILE__, 'w') do _1.write script _1.write "__END__\n" _1.write DATA.read _1.write value end __END__ iPad Firefox Android 実行すると次のよ
プログラマにできるとよさそうなこと - @ledsun blog
十行程度のプログラムが読めること プログラミング言語の文法を知っている 分岐とループを追いかけることができる 変数の状態変化を追いかけることができる 関数呼び出しを追いかけることができる 十行程度のプログラムを複数回書いたことがある プログラムを読んでプログラムの動的な振る舞いを想像できる プログラムの主な処理の結果を想像できる 主な処理の終了条件がわかる プログラムから主な処理を読み取れる 似たようなプログラムを書いて、動かしたことがある 既知のプログラムと読んでいるプログラムの違いがわかる イディオムを知っている イディオムを書いたことがある プログラムがどう動くか知っている 重複したソースコードを関数に抽出できる 重複したソースコードがわかる 同じ入力と出力をもつコードブロックがわかる コードブロック単位で入出力を比較できる プログラムのある機能がソースコードのどの部分に依存している
#TestingFrameworkMeeting に参加しました（１） - テスティングフレームワークの歴史 - @ledsun blog
参加した時のメモです。 t-wadaさん Testing Framwork Meeting テスティングフレームワークの歴史 http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。 有史以前 make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。 JUnit Kent BeckがJUnitを書いた。 1994 SUnit 1997 JUnit プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。 テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。 自動テス
メンバーの教育を（有期の）プロジェクトリーダーの責務に入れてはいけない - @ledsun blog
t.co を読んで考えた話です。 30歳近くになっても無能、ということは、そいつはほとんどの場合、一生無能だ と刺激的な言葉が使われています。 状況を限定すれば、一理あると感じる点があります。 表題の「メンバーの教育を（有期の）プロジェクトリーダーの責務に入れてはいけない」です。 結論 プロジェクトリーダーの最大の責務はプロジェクトを成功です。 メンバーの教育は、プロジェクト成功の阻害要因になっているときだけやります。 無能なやつには、意見を聞いても、ろくな話は出てこない。時間がもったいない の例では、「意見を聞かない」という簡単な回避策があります。 回避策があるときは、教育の手間を掛けてはいけません。 そうは言っても、一緒に仕事する仲間はできるだけ賢くあって欲しい、自分の足を引っ張らないで欲しいと思うのが人間です。 教育は誰がやればいいのか? ティーチングとコーチング メンバーの教育は上
エンジニアの採用面接対策 - @ledsun blog
paiza.hatenablog.com に、面接で落とした理由があります。 最近は技術者が面接をすることが多いです。 技術者は採用面接に不慣れなことが多く、質問が下手くそです。 面接官側の不手際で、コミュニケーションに齟齬があって落ちていることもあると思います。 自分の採用面接経験での「こういうことが聞きたかったんだよ」という辺りを書きます。 実践すれば面接に受かることを保証するものではありません。 1位：自己表現(プレゼンテーション)力 職務経歴を聞かれて、一から十まで細かく説明しようとする人 面接の最初にお互いの緊張をほぐすために、自己紹介をしてほしくて使います。 面接官がどっから本題に入っていいのかわからないので、とりあえず聞いてみます。 30秒〜1分くらいで、簡単に説明してもらえれば良いです。 内容よりは、喋り方を見ています。 評価をするためよりは、これから会話をして行くときに「
「有名な統計力学ゲーム」をcanvasで表示してみる - @ledsun blog
今回のテーマ 前回の ledsun.hatenablog.com では、やり取りの結果をSVGのレーダーチャートで表示しました。 SVGではやり取りが1000回を超えると快適に表示できませんでした。 今回は、canvasのレーダーチャートに表示します。 チャート See the Pen statistical_mechanism_on_canvas_chart by shigeru.nakajima (@ledsun) on CodePen. さすがはcanvas、圧倒的な描画性能です。 やり取りを一万回ぐらいやるとバランスよく星型になるのがよくわかります。 ちょっとした工夫 canvasであっても1万回描画すると*1それなりの時間がかかります。 そこで複数回のやり取りをまとめて描画しています。 かつ、やり取り回数が多い時は、たくさんまとめて、少なく立ってきたらまとめる数を減らして描画して
失敗プロジェクトの弔い方 - @ledsun blog
プロジェクトを燃やした経験から、どうすれば有効なふりかえりができるのか考えてみました。 要約 失敗プロジェクト参加者の信用を回復 失敗プロジェクトの撤退戦術を共有 失敗プロジェクトの回避方法を検討 背景 「社内の失敗プロジェクトを振り返って今後に活かそう」みたいな会があったので失敗のポイントを明確にすべく張り切って他のPMに質問しまくってたら「そんな傷口を抉るようなことするな」と怒られが発生したので人間界には主旨はなく気持ちだけがあると悟った回。— モーくん (@calfscalf) 2017年5月9日 を見て考えました。 外野から見たら、確かにまったくこう見えると思います。 なぜ、傷口を抉るようなことをするなと言いたい「気持ち」になるのでしょうか？ 失敗プロジェクトの当事者の立場 デスマると、渦中の人は如何にして心を折らずに終戦までもっていくかがんばっている。社内からは、あいつらのせいで
1on1ミーティングのやり方 - @ledsun blog
1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。 前提条件 弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。 インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。 面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。 やり方 人数 インタビュワーは6人います。ベテランエンジニア5人と営業1人です。 インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。 組み合わせ もっとも長い期間面談をしていない組み合わせで実施します。 組み合わせは、モンテカルロ法で抽出します。 そ
中間業者を中抜きすると受発注者はWin-Winになるか？ 事例：クラウドワークス - @ledsun blog
結論 事例：クラウドワークス クラウドワークスは発注者のためのサイト 中間業者中抜きへの期待 先人の失敗 絵や音楽 伝統工芸 価格維持力が失われる 中間業者が必要な構造 クラウドワークスの価格低下構造 受注者は増える 価格下げ圧が強すぎると市場は縮小 中間業者の機能1 参入障壁（受注者のフィルタリング） 中間業者の機能2 案件のバッファリング クラウドワークスさまへのご提案 参考リンク 結論 中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう 事例：クラウドワークス crapp.hatenablog.com にて、受注者側から見たクラウドワークスの問題点が挙げられています。 クラウドワークスは発注者のためのサイト クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった また 発注
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
