タバコの吸殻をカラスに集めさせるというアイディア | スラド デベロッパー
オランダ・アムステルダムのデザイナー2人が、街に捨てられたタバコの吸殻をカラスに集めさせるという装置「Crowbar」を考案し、実験を計画しているそうだ(公式サイト、 The Next Webの記事)。 タバコの吸殻は最もポイ捨てされやすいものであり、オランダでは年に60億個以上の吸殻が街に捨てられているという。タバコのフィルターは多くがアセテート繊維で作られており、分解されるまでに何年もかかる。2人は吸殻を回収する方法を検討した結果、Crowbarのアイディアにたどり着いたそうだ。カラスを選んだのはアムステルダムでよく見かける動物の中で最も賢いためで、カラスにコインを集めさせるオープンソースハードウェア「Crow Box」にもインスピレーションを受けたという。 Crowbarの仕組みとしては、装置下部にある漏斗状の部分に吸殻を落とすと上のトレイに餌が出てくるというものだ。カラスにCrow
コードのインデントにスペースを使う開発者はタブを使う開発者よりも高収入という調査結果 | スラド デベロッパー
Stack Overflow 2017 Developer SurveyのデータをStack OverflowのデータサイエンティストDavid Robinson氏が分析したところ、コードのインデントにタブを使う開発者よりもスペースを使う開発者の収入が高いという結果が出たそうだ(Stack Overflow Blogの記事、 The Registerの記事、 Ars Technicaの記事)。 回答者51,392名のうち、インデントにタブを使うかスペースを使うかという設問に回答したのは28,657名。プロの開発者の回答に限定すると40.7%がタブ、41.8%がスペース、17.5%が両方となっている。このうち12,426名が給与(年間)の情報を回答している。 給与の中央値はインデントにスペースを使用する開発者が59,140ドル、タブを使用する開発者は43,750ドルとなっている。両方使用する
/.Jに聞け：世間ではプログラマが足りていない？ | スラド デベロッパー
やねうらお氏のブログ記事「世間ではプログラマが足りていないらしい」によると、世間ではプログラマの求人需要に対し、供給は不足しているらしい。 あくまでやねうらお氏が周りの会社から聞いた話ということらしいが、実際のところはどうなのだろうか？
「オブジェクト指向言語でオブジェクト指向っぽいプログラミングをしない」のはNG？ | スラド デベロッパー
「オブジェクト指向言語でオブジェクト指向プログラミングをしない」というSEのブログ記事が一部で物議を醸しているようだ（タレコミその1、タレコミその2、argonの日記など）。 話題になっているのは、@IT内の「システムエンジニア 生き残りの極意」ブログの「実はオブジェクト指向ってしっくりこないんです！」という記事。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。
週に何時間プログラミングできる? | スラド デベロッパー
フルタイムのプログラマーは、1 週間に何時間プログラミングできるものだろうか。自分は調子がいい時で週 20 時間、大体において 10 〜 15 時間といった感じで、40 時間近くになるとかなりクタクタになってしまう。 ここでいう「プログラミング」とは実際にコンソールに向かい入力していることを指している。もちろん時々手を止めて考えることもあるだろうが、プログラミング書籍や仕様書を読んだり、会議に出たりする時間は除いている。そういった時間はプログラミングと比べればランチ休憩のようなものだろう。 自分は幸いにも会議が少ない方であるが、脳みそのオーバーヒート防止のために週数時間はネットサーフィンに当てている。基本的には tech 系のニュースを読んだり、たまにメールや Facebook を覗いたりしている。また、自分は IT 部門用のイントラネット用ウェブアプリの担当でもあり、同僚と共に電話対応し
いいコーディング規約、悪いコーディング規約？ | スラド デベロッパー
本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。 可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？ /.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか？ 逆に規約のせいで問題が起きてしまったケースなどあるだろうか？ 他にも、使える「自分ルール」などもあれば是非。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代的な Perl を再習得する方法は？ | スラド デベロッパー
Ruby公式ロゴ決定 | スラド デベロッパー