【教えてくん】コミュニティーなのです。 なんかニュースとかあったらここに書こうかと思ってますよ。とりあえず、おいらのブログ
1: 以下、\(^o^)/でVIPがお送りします 2014/12/29(月) 13:23:22.49 ID:aDj/zqBFNIKU.net if文for文使いまくってるのってキモいよな 2: 以下、\(^o^)/でVIPがお送りします 2014/12/29(月) 13:24:15.50 ID:/y8HWckGNIKU.net じゃあ代わりにswitchとwhile使う 3: 以下、\(^o^)/でVIPがお送りします 2014/12/29(月) 13:24:18.06 ID:afkjonbrNIKU.net switch 6: 以下、\(^o^)/でVIPがお送りします 2014/12/29(月) 13:25:46.44 ID:5e4wCC7eNIKU.net 3重switchできたった 4: 以下、\(^o^)/でVIPがお送りします 2014/12/29(月) 13:25:07.80
結論 小手先で楽をするためのボトムアップな設計は後々苦労する 継承を使った差分プログラミングは長年運用していくと大変だ 人は楽な方に流れるので、Baseクラスで解決すべきでない問題をBaseクラスで解決して後で困る はじめに この文章は2015年1月のpotatotips13で発表するネタ用のメモに書いてました。 実際に発表した内容を含む様子は下記のページにまとめています。 http://curiosity.co.jp/potatotips13/ 会場で質問されたりツイートの様子を見てて気づいたのですが、BaseViewControllerを使いたくないという"この文章"と同意の意見は、比較的経験のあるおじさんたちの意見であって、若い人からするとなぜBaseViewControllerを使ってはいけないように言われるのかについて具体例を聞きたがる傾向が強いです。 また、不必要に自分が気に入
http://techcrunch.com/2015/01/01/everyone-in-management-is-a-programmer/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 この先、ソフトウェアの力でビジネスの競争力に格段の差がついてくる産業がどんどん増えてくることに備えて、プログラミング教育の必須化の議論も盛んですが、その必須化の是非はさておき、将来的には社会人になるうえで、ある程度コードを理解できる素養があることがもっと当然のことになってくるのではないかと期待してます。 そうなると、今の世の中の人が漠然と持っている、「エンジニア」と「非エンジニア」という言葉から連想してしまう偏見、両極端なイメージは、いずれの側に属する人々にとっても将来はもっと不利益になるかと。相互理解が必要です
年末からはてな村界隈を騒がせていた、株式会社参謀本部の件。 なかなか面白い内容だった。 正直、当事者どうしの問題に関してはあまり興味はなく「労働審判でも起こすしかないだろ」(正直、労基署はあまりオススメしない)ぐらいの事しか思わないのだが、今回の一件で思い知らされたのは、 小規模の組織にとって、「やる気はあるが責任はない」人は害悪 ということである。 「やる気はあるが責任はない人」とは 「やる気はあるが責任はない」というのはつまり、業務を遂行していくやる気があり、人や組織に対していろいろ意見をするが、その人自身は責任を取る立場にない人、ということになる。 今回の騒動で言えば、株式会社参謀本部の責任を取る人、といえばもちろん経営者=株主である。 だが、当該の人(個人攻撃が目的ではないので、直接名前を記すことは控える)は株主ではなく業務委託らしき雇用状況*1なのに、会社の行く末を案じて様々な発
今日は、開発者が見積もりを作成している時に脳内でどんなことが起きているのか話してみたいと思います。なぜこんなにも見積もり作業が難しいのか、そして、私の見積もり精度は相変わらずひどいものですが、私がどうやって(非常に幸せな事業主の方々に向けて)ソフトウェアを書いて生計を立てる術を編み出してきたのかについてお話ししたいと思います。 まずは昔話をひとつ。 あれは<私がものすごく年寄りには見えない程度の年代をここに挿入>頃でした、私は年若き開発者でした ^(1) 。大学のコーディング演習では優秀な成績を修め、若手開発者として誰がどんな問題を提示してきても解決し、想像を絶する速さでどしどしコードを量産していました。新しい言語は週末の間に習得し、書けるようになっていました(少なくともそう信じていました)。 それで自然な流れとして自分でプロジェクトを取り仕切ることになりました。アカウント・マネージャが大
先日、島根県の松江で行われた「松江Ruby会議06」というイベントで講演をしてきました。講演のテーマは『「納品のない受託開発」とエンジニアの働きかたのこれから』というもので、「納品のない受託開発」「地方」「Ruby」「ギルド」について話して欲しいと依頼を受けました。 色々と新しいネタも入れた資料ですが、今回の記事では、地方で働くエンジニアについて、その講演で話したことをもとに考えてみたいと思います。 “地方”を言い訳にしている人たち あちこちの地方に講演で伺うことも多く、懇親会などに参加すると地方における問題を聞かされます。確かに様々な問題があるのもわかります。だからといって何か提案をしても「そうはいっても地方だと難しい・・・」という言葉をよく聞くのです。 しかし、果たして本当に「地方」が問題なのでしょうか。 そこで思い出すのは、東京にいても現状を変えようとしない人たちの言葉です。彼らはこ
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう(そういう人は結構たくさんいる)。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
ファン驚愕の急展開、その真意とは!?本日(2014年12月26日)に突如発表された、iPhone、Android版『拡散性ミリオンアーサー』(以下、『拡散性』)サービス終了の一報。 スマートフォンのゲームアプリを代表する人気作である『拡散性』。一時期はセールスランキングの上位に居続け、ここ数カ月は順位を落としていたものの、なぜこんなにも急な配信終了発表となったのか。 本作のキーマンであるスクウェア・エニックスの安藤武博氏、岩野弘明氏のふたりに直撃した。 ――まず、『拡散性』が終了することになった率直な理由を教えて下さい。 岩野弘明氏(以下、岩野) いまだからお伝えすると、もともと『拡散性』を配信する前後で、とあるどうしようもない事情からコアスタッフが抜けたんです。その状態で運営を続けていき、ありがたいことにヒットはしていたのですが、それ以降に新しい展開や盛り上げ施策を行おうとしても、うまく
業務改善の“やらされ感”をなくする方法とは 傍観者ばかりの“無関心な現場”で進める業務改善。あなたが部門の責任者や、改善活動の事務局など改善活動を率先する立場だったら、どのように進めていくでしょうか? 一般に、業務改善は即効性のある効果が期待されることが多く、どうしても現場には「改善効果のアウトプット」が早く求められます。しかし、そこには動かない現場。変わりたくない社員という大きな壁が立ちはだかります。あなたはそんな現場に対して、イラッとしてしまうかもしれません。 「二度とやるものか…」と思っている社員に対して、頭ごなしに「やれ!」と言っても、うまくいかないのは目に見えています。改善に対する“やらされ感”をなくし、当事者意識を持たせていくかが業務改善の成功の鍵となります。 今回は、この“やらされ感”をいかに感じさせることなく、自ら積極的に関わっていくようにしていくかを考えてみま
今、Node.jsに起きてることを語る上で、io.jsは避けて通れない話題でしょう。 今回のNode.js アドベントカレンダー 2014の締めを飾るために、このio.jsについて僕が知っている限りの事をまとめて書くことにします。 io.jsを知り、今後"Node"がどうなっていくのかを皆で一緒に考えていきましょう。 またこの一連のio.jsのfork騒動はOSSという特殊なプロジェクトをどう進めていくのがハッピーなのかを知る一つの教材だと思います。 OSSに関わっている皆さん、今回も長いですが、最後まで読んでもらえると幸いです。 io.js とは何か Node.jsのForkです。次のNode.jsの安定版になる、v0.12をForkしています。「アイ・オー ジェイエス」と読みます。名前の由来は木星にある四番目に大きな衛星の名前から取られました。*1 Nodeを使っている人のことをnod
はてなCTOのid:stanakaです。 はてなアドベントカレンダー2014も最終日となりました。 今年のアドベントカレンダーは、スマートフォンアプリ開発からシステム系論文の話まで幅広いテーマが集りました。 読んでいて優秀なエンジニアがいるなぁ、としみじみ思います。 ちなみにアドベントカレンダーは25日までじゃないのか、という話がありそうですが、本来は24日までだそうです*1。 CTOとは何か論 最終日の今日は「CTOの役割と組織における技術的ポートフォリオの組み方」について考えているところを書いてみます。 最近、なぜかCTO論が盛んで、あちこちでよく耳にするようになってきています。 rebuild.fmでのnaoyaさんのマネージメント話や、WEB+DB Pressの舘野さんの連載などでもCTOやエンジニアのキャリアについての話が盛り上がっています。 つい先日でたWEB+DB Press
はじめに これは ドリコム Advent Calendar 2014 の23日目です。 22日目は、シモーネことryouichi.horiiさんによる リリース時の負荷対策 - Qiita です。 自己紹介 @tomofusaです。 ドリコム入社9年目。 サーバーサイド出身で、ゲーム/クライアント周りの技術を見るマネージャー。 手を動かさない方の部長です。 CTOを目指しています。 最近気になっているのは、ゲーム開発/アドテクです。 ※一部の方を除いて目標CTOについては、はじめてパブリックにしました。 もうちょっと詳しく 元々は、学生時代に総合工学部的なところからソフトウェア開発に入りました。C/C++の基礎的なものに触れながらwin32/.NETでツールを作って遊ぶ程度のプログラミング経験でしたが、インターネットの画く世界に魅せられて、興味をもったことからweb業界に入ってきました。
「ダニング・クルーガー効果」をご存じですか。これは、筆者お気に入りの、ビジネスにまつわる心理学理論であり、非常に示唆に富んでいます。簡単に言えば、「能力のない人ほど自信にあふれ、本物の実力を持つ人ほど自らの能力に疑いを抱いて悩む」というものです。「ダニング・クルーガー効果」という名前は初耳でも、思い当たる節があるのではないでしょうか。この理論を提唱したのは2人の心理学者で、その名の通り、デビッド・ダニング氏とジャスティン・クルーガー氏です。しかし、こうした心理的バイアスに、もっと以前に気がついていた人がいました。イギリスの哲学者バートランド・ラッセルです。ラッセルは、ダニング氏とクルーガー氏よりもずっと前に、的確にこう言い表していました。「世界が抱える問題は、愚か者が自信に満ちあふれていて、賢い者が疑念を抱えていることだ」 ダニング・クルーガー効果に関しては、困った点が1つあります。この理
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットしても、後できれいにコミッ
こんにちは、インフラストラクチャ本部のあだち(@foostan)です。 このエントリは GREE Advent Calendar 2014 19日目の記事です。昨日はにしだ(@hosi_mo)さんによるネイティブゲームクライアントの幸せな設計図でした。 今年のグリーアドベントカレンダーのテーマは「GREEを支える技術」ですが、私からは「GREEを支えるかもしれない技術」としてConsulについてご紹介します。 本エントリの対象者 本エントリでは、簡単なWebシステムを例にとって、Consulやその周辺ツールの基本的な使い方やオーケストレーションする仕組みについて説明していきます。 なので Consulって何? Consulって便利そうだけどどうやって使うの? Consul触ってみたけど、使いどころ分からないんだけど? オーケストレーションって? と思われた方にとって良い情報源になることを期
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか? 今後、この呼び出しを変更したり削除したりしても安全でしょうか? // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く