エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
マネジメントの放棄を正当化するような格言めいたものがこの世には流通しているかもしれない - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ちょっと前にツイッターで以下のようなことを書いた。 「自分で考えて動く」みたいなのすごい大事だとぼくも思うけれど、それをするためには「どんな役割を担ってほしいか」「達成してほしいことはなにか」「どこまで自分の裁量でやっていいか」がそれぞれ明確になってないと無理だよね。逆にそこさえ揃ってれば、よほどのタコじゃない限り自分で動くと思う これに対して、「マネージャーがそれをやらないのはマネジメントの放棄だよね」というリプライがついて、「なるほどたしかにそうだなあ」と思ったのだけれど、マネジメントの放棄と呼ぶべき状況ってのは、これの他にも、ちょっと注意して見てみるといろいろなところで目にすることがあるかもしれない。 たとえば、たまに耳にする「社会人は結果が全て」という言葉について。ここでいう「結果」というのはなんだろう。マネジメントするひととされる人の間で「あなたが達成すべき結果はこれですよ、これ
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
