東京＆広州パワー生活者 @guangzhou88 私は完全文系の高校出て、ＩＴ業界に３０年以上いますので、生き残っていると思ってます。 私の周りに企画提案書や成果報告書をまともに書ける人とまだ出会った事がありません。 ＩＴ業界は理系ばかりだからですが、実際ＩＴ業界で数理計算などする事はありません。プログラムも文法です 2015-11-13 17:23:41

ワカモノは悩んでいるらしい 自分は今年で旧エヴァのミサトさんと同い年という感じで若くないせいか、たまに自分より年下の知り合いに会うと、仕事の悩み相談みたいな展開になることが多い。 会社もバックグラウンドも年齢もそれぞれ違う彼らの悩みは多種多様であるように聞こえていたのだが、最近ある共通点に気づいた。「このままじゃいけない」と無意識に思い込んでいる点である。 今以上にスキルをつけなければいけない、成長しなければいけない、ユニークな仕事をしなければならない、など人によって異なるのだが、なぜか「～なければいけない」の思いを持っていた。 そしてもう一つ共通しているのが、その「～なければいけない」の目的が見えないという点である。何となく焦っているのは分かるのだが、その焦って行動した結果によって自分が何を得たいのか。これまで色んな悩み人と会ったが、共通してそれが見えてこなかった。それとなく中長期的な計

20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「＠Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」（単一コードベースへの取り組み：なぜGoogleは単一リポジトリに数十億行ものコー

「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても

shi3z @shi3z @takagiichiro あのトラブルはアプリ書いた人の能力の問題だと思いますけどね。僕には高木先生が「今更なにいってんだ」と思いましたし、今更高木先生に迎合して再圧縮を批判してる人は携帯電話使いたくないのかな、と思いましたが 2015-07-24 08:01:34 高木一郎 @takagiichiro @shi3z 能力に問題はないのでは。すぐに回避する対処はなされていましたし。平文のHTTPであってもデータの同一性を求めるのは間違った期待だとは思いません。悪意を持った攻撃者による漏洩や改ざんのリスクを鑑みて内容によって平文通信で良しとする判断は一般的なものでしょう。 2015-07-24 08:47:14 shi3z @shi3z @takagiichiro 「通信の最適化」議論に関してはそもそもhttpが平文でやりとりするものである以上、途中の経路で何が起

吉良理人@ねもい @big_bros ゲーム畑出身のフリーランスSE/プログラマ、VOCALOIDで遊ぶDTMerのにわかギター弾き。秋葉原酔狂楽団(仮)楽長。日本飯盒協会員。投稿動画bit.ly/ePqOuE ピアプロpiapro.jp/bigbros まとめ kadongo38氏「日本の通信事業者よりAppleやFacebook, Google の方が問題」 「通信の最適化」でモバイル通信事業者が音声や画像をトランスコード（再圧縮）などする件が話題となっています。 これついて、kawango38氏による高木浩光氏への批判と、同調する意見への批判、及び、それへの反応。 主に、通信の秘密への侵害を問題視する意見への反論。 有益な情報や喧嘩腰な発言など雑多に集めたものです。 kadongo38氏によるshi3z氏のフォローと、それに続くtakagiichiroとの会話 http://toge

Android と iPhone との比較は多くの点で議論されており、どちらがより良いかは、Android の画像の質は iPhone とくらべてずっと劣るという点を除けば、未だ結論が出ていません。Facebook、Twitter、Instagram 等どれを使っていても、写真をとって、フィルタをかけて、ソーシャルネットワーク上に公開すると、いつも Android から投稿される写真は画質が劣化しています。しかし何故でしょう？ 私達は昨年の間調査をし、そしてついに、Google が犯したほんのちょっとしたミスが原因であることを突き止めました。それは本当にちょっとしたミスでしたが、その影響はすべての画像を扱うアプリケーションに波及するほど大きく、現在に亘っても影響が続いています。 問題は、libjpegです。 libjpegといえば、数多くのオープンソースプロダクトでも使用されており、And

2015.06.03 スキル 社会人になったばかりの若いエンジニアの中には、一度この道に足を踏み入れたからには、自らの技術一本で身を立てていけたらという、強い思いを胸に秘めている人も少なくないのではないか。 そう考えて今回、Rubyの父として知られるまつもとゆきひろ氏に、あえて「これからの時代に技術だけで生き残るには？」という偏ったテーマで取材を依頼した。返ってきたメールの冒頭にあったのが、次の一文である。 「技術だけで生きるというのは幻想である」 まずはその真意を聞くところから、取材は始まった。 まつもとゆきひろさん(@yukihiro_matz) 1965年生まれ。筑波大学第三学群情報学類卒業。プログラミング言語Rubyの生みの親。株式会社ネットワーク応用通信研究所フェロー、一般財団法人Rubyアソシエーション理事長、Speeeをはじめとした複数社の技術顧問、Herokuチーフアーキテ

プログラマがよく使う「hoge（ほげ）」や「hogehoge（ほげほげ）」。プログラムのサンプルコードなどで、特に意味がない、何を入れてもかまわないときに使う言葉として、おなじみですよね。もっと一般的に例えるなら、書類の記入例などで「○○太郎」「（地名や会社名）花子」などと書かれているのに近い感じでしょうか。 そんなhoge、一般用語ではないにしても、コンピュータ業界なら誰でも通じる言葉……と思っていたら、そうでもないことがネットで話題になっています。 注目を集めたのは、“【え、通じない？】教授「hogehoge...」学生「何いってんのこの人？“というまとめ。 togetterまとめ 学生さんと思われる発言者による「情報の課題ついでに、先生に質問しておいた」「お願いです、先生。教えてください、気になるんです！　この間はHOGEMETHODとか言ってたじゃないですか。何ですか、ホゲメソッド

2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その

「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり

2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造

ｃonstexpr関数はコンパイル時処理。これはいい。実行時が霞んで見える。cpuの嬌声が聞こえてきそうだGenya Murakami

はじめに 僕は、競技プログラミング、という競技で、トップクラス、とギリギリ呼べるくらいの選手です。こうした実力をキープするのに、一番大切なのは、練習を続けることだと思っています。練習を続けるにはどうすれば良いでしょう？たくさんの練習をするには、モチベーションを高める必要性があります。 さて、それでは、どうしたらモチベーションが高まるか？僕は、ちやほやされるとモチベーションが高まります。世界○位を取ったら嬉しい、というのもありますが、「世界○位なんてすごい！！！」とちやほやされる方が嬉しいくらいかもしれません。 さて、そんな自分ですが、最近ちょっと問題があります。 ある程度良い成績を取るのが当然になってしまったので、多少良い成績を取ったところで、誰もちやほやしてくれなくなってしまったのです。困った。これは困った。これではちやほやしてもらえない。これでは、現在の実力を保つことが出来ません！ さ

もう終わりそうですけど、４月ですしこれから組み込み業界へ向かうかたへ自分がこの本よかったなーって思ったのをいくつかピックアップしてみます。ただ、一言に『組み込み』と言っても幅広くて分野によって求められる知識は結構変わってくると思いますが、ベースは一緒だろうと思います。 ちなみに自分はCPUはRL78、Cortex-M0、Cortex-M3、Rx、SH、Cortex-A9、FPGAは最大でも7000LUT程度のレンジのハードウェア設計をやってきました。今はZynqや大規模FPGA開発に携わりたいと思っています。 以下に挙げていきますが、オススメがあれば是非教えていただきたいです。 ※順番に意味はありません。 CPUの創りかた CPUの創りかた 作者: 渡波郁出版社/メーカー: 毎日コミュニケーションズ発売日: 2003/10/01メディア: 単行本（ソフトカバー）購入: 35人 クリック:

Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

騒動についてはじめに、今回の騒動について語る。ついにスラドに取り上げられたので、以下のスラドを見れば大まかには分かるだろうが、多くの人が事実を誤解していると思うので、釈明したい。 「年功序列などで働きづらい」として転職した元日立社員、転職後「日立のほうが良かった」と後悔して話題に | スラド 現職VA Linuxに入社後すぐ、もう一年前のことになるが、素晴らしい功績をスラドに取り上げられて(第9回日本OSS貢献者賞・奨励賞の受賞者、発表される | スラド)、いよいよ開発者としてキャリアを始めようかという時にこの惨事なので自分の社会不適合性が嫌になる。私は過去にも散々、掲示板やSNSなどでやらかしてきた。しかし私は根っからの異常者ではない。私という人間に興味があって会う人は口々に「ふつうだ」という。ネット社会の私が、完全な異常者なのだ。ちなみにリアルの私は、自己評価になるが、極めて素敵な好青

こんにちは、投稿推進部の吉田(@101kaz)です。Androidアプリの投稿周りの開発を担当しています。 去年クックパッドに入社したことをきっかけに、本格的にAndroid開発をするようになりました。 今回は私のような開発をはじめて日が浅い人が見落としがちな「非同期処理時のNPE(NullPointerException)」と「Activity破棄に関する問題」と「ProGuardの設定忘れ」について実際の遭遇した事例をベースに紹介します。 非同期処理コールバック時のNPE ある時Fragmentから非同期処理を行い、コールバック内でFragmentの内のviewにアクセスするコードを書きました。 @Override public void onActivityCreated(Bundle savedInstanceState) { ApiClient.getRecipes(new Ap