GitHubを快適にブラウジングするための3種の神器みなさん、連日 GitHub をブラウジングしてると思うんですが、より快適にブラウジングできる拡張機能を紹介したいと思います。
ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
若い会社でエンジニア組織の上司として大切にしていること3つ - netmark.jp
4月、新生活、な雰囲気。 というわけでたまにはポエミーなことも書いてみます。 新たに部下を持つことになった人もいると思うので、 そんな人に役に立つかもしれない、 私が上司として大切にしていること3つを紹介します。 前提として、 HRやリーダーシップについて大学院やものの本である程度知識はつけているものの、 きちんとした専門のトレーニングを受けているわけではありません。 なにか勘違いとかがあれば教えてください。 人材マネジメントも組織マネジメントもプロジェクトマネジメントも得意なわけではないですが、 現実的に直轄の部下が20人近くいるわけで、 なかなかに悩ましいところであるわけです。 短期的な視点と長期的な視点は両方持ちつつ、 落とし所を探しながら日々過ごしています。 その1: 自分を基準にしない 思い遣りがないと感じられるかもしれませんが、 「自分だったらどうか」 「自分だったらどう感じる
大経営者たちがプログラミング教育の必要性を唱えることに対して全然喜べない理由【連載:村上福之】 - エンジニアtype | 転職type
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ >> 「日本史なんかより、プログラミングを教えるべき」三木谷浩史氏と夏野剛氏が日本の技術者不足を嘆く こういう考え方、今っぽいし、悪くないとは思うんですけど。個人的に、プログラム教育とか論じてる人が「プログラマーとして飯を食ったことがある経営者」じゃないとちょっとゲンナリするよね。 僕は三木谷さんや
第1回 エンジニアがなかなか採用できないワケ | gihyo.jp
「エンジニアがほしいのに、求人がない！」と人事が嘆いている現状 「だれか知り合いに転職したいと言っているエンジニアはいない？」 私は「CodeIQ」というエンジニア採用のためのWebサイトのプロデュースをしているのですが、エンジニアが自社の人事から耳元でこの台詞をささやかれているという話を、頻繁に耳にします。 仕事柄、転職マーケットのデータをたくさんみる機会があるのですが、転職マーケットにエンジニアはなかなか登場しません。ようやく求人があっても、企業が採用したいという水準に達していないケースが多かったりします。出現したらしたで、取り合いになること必至です。 この連載を読んでいるあなたも「ああ、確かにそういう状態だな」とか、むしろ「なにを今さら言っているのだ」と思うかもしれません。 けれども、エンジニア採用の実務を担当する企業の人事、とくにエンジニア出身じゃない採用担当者は「わかってはいるけ
エンジニアと非エンジニアの境界 - ワザノバ | wazanova
http://techcrunch.com/2015/01/01/everyone-in-management-is-a-programmer/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 この先、ソフトウェアの力でビジネスの競争力に格段の差がついてくる産業がどんどん増えてくることに備えて、プログラミング教育の必須化の議論も盛んですが、その必須化の是非はさておき、将来的には社会人になるうえで、ある程度コードを理解できる素養があることがもっと当然のことになってくるのではないかと期待してます。 そうなると、今の世の中の人が漠然と持っている、「エンジニア」と「非エンジニア」という言葉から連想してしまう偏見、両極端なイメージは、いずれの側に属する人々にとっても将来はもっと不利益になるかと。相互理解が必要です
コーディング ファスト＆スロー: 開発者と自信過剰の心理 | POSTD
今日は、開発者が見積もりを作成している時に脳内でどんなことが起きているのか話してみたいと思います。なぜこんなにも見積もり作業が難しいのか、そして、私の見積もり精度は相変わらずひどいものですが、私がどうやって（非常に幸せな事業主の方々に向けて）ソフトウェアを書いて生計を立てる術を編み出してきたのかについてお話ししたいと思います。 まずは昔話をひとつ。 あれは\<私がものすごく年寄りには見えない程度の年代をここに挿入>頃でした、私は年若き開発者でした ^(1) 。大学のコーディング演習では優秀な成績を修め、若手開発者として誰がどんな問題を提示してきても解決し、想像を絶する速さでどしどしコードを量産していました。新しい言語は週末の間に習得し、書けるようになっていました（少なくともそう信じていました）。 それで自然な流れとして自分でプロジェクトを取り仕切ることになりました。アカウント・マネージャが
RE: どんなことを勉強すればいいですか？ - satococoa's blog
仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか？」です。 それについてちょっとポエムを書いてみようかと思います。 主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。 専門家であるという視点から エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。 僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な
Railsを作った男たち - Qiita
あいさつ Railsアドベントカレンダー16日目です. いい感じに中だるみして来たのでトンズラここと思いましたが筆、執りましたよ. Railsに限らずOSSのすごいエンジニア（小並感）に感化されるのは良い事だと思います. （画像の使用許可等はちゃんと取りました. 画像無い方は許可取れませんでした.） Railsは本当に多くの方々のお力によって作られているとは思いますが、 今回は僕の恣意的な選択によって数人の方を挙げさせて頂きました.（基本的にはコミット数） David Heinemeier Hansson(DHH) Github: dhh Blog: DAVID HEINEMEIER HANSSON Twitter: @dhh Railsの生みの親. 2004年7月にオープンソースとして公開するも、2005年の2月までコミット権を誰も渡さなかったとか. デンマーク生まれで写真家で尚かつカー
基盤系プログラマ - kuenishi's blog
いわゆる基盤系のエンジニアリング技術について、私の場合は、今の会社に入社して２年間で徹底的に叩き込まれました*1。C言語なんかは独習の範囲内であって、コンピュータに関する基礎的な知識が不足していると痛感しています。一方、Computer Scienceに関する基本的なトピックはシンプルなものが多いので、数学の素養と、大学で詰め込まれた技術があれば何とかなる感じがしています。 飽くまでも、ですが、OSとかRDBMSとか、全ては手段です。ビル建設でいえば生コンのようなもの。砂利とか。肝心なのは、自分が欲しいビルの理想をきちんと描き、実現までの手段・手順を整理する。理想としているビルができているかを確かめる。難しいのは、「そんなビルが技術的な観点から本当に建設できるのか？」を確かめながら進むこと。 あるいは、それらの技術を全て、日本語にしてきちんと表現すること、設計を周囲に伝えて合意をとること、
日本のデータベース系のコミュニティ、なぜイマイチ盛り上がらないのか - kuenishi's blog
11月の19,20日に開催されたWebDB Forumに参加してきた。カンファレンスそのものは、いろんな人に久しぶりに会えたり、ネット上でなんとなく知っていても話したことなかった人と話したり、意外な人の意外な一面をみることができたりと、とても楽しむことができた。立場としては所属している会社のスポンサー枠で参加して目的もあって発表もしてきたわけだが、いくつか思うところがあるのでここにまとめておきたい。 現実にアカデミックで起きていること WebDB Forumと銘打ってはいるものの、データベースに関する研究発表は非常に少ない。OSやネットワーク、システム系の研究と併せても、機械学習やNLP、Webなどの技術に感心を持つ人は多く数で圧倒されている。体感では 90% だ。それをいえば別に VLDB や SIGMOD などのトップカンファレンスもデータベースの技術を直接扱うことは少ないし、データベ
これからプログラミングを始める人のベンチマークとして「僕の12年間のプログラマ人生」を振り返ってみた - give IT a try
はじめに：「これは何ですか？」 これは12年前から現在に至るまでの僕のプログラマ人生を振り返ったものです。 また、参考情報としてプログラマ人生が始まる前の中学時代～大学時代の話も載せています。 photo by Philip Bloom あ、僕のプログラマ人生はまだ継続中ですので念のため！ 「何のためにこれを書いたんですか？」 このエントリを書いた目的は、これから本格的にプログラミングを始めようとしているみなさんのベンチマーク（目標や計画を立てるための参考情報）にしてもらうためです。 最近、「これからプログラミングを始めようとしています」もしくは「最近プログラミングを始めました」という人に出会う機会が増えてきました。 これからプログラミングを始める人は「どうすればプログラミングが上達するのか」「一人前になるまでにどれくらい時間がかかるのか」「どういったキャリアを歩めばいいのか」というイメー
Martin Fowler氏の語る“犠牲的アーキテクチャ"
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
第2回 見つからないエンジニアを探し出す技術 | gihyo.jp
能力に自信がないのは、評価する機会に恵まれていないことの裏返し 「自分にそんなに自信を持っているエンジニアはいませんよ」 先週、とあるエンジニア対象のイベント（トークショーのゲストとして出演していました）で出会ったエンジニアの多くは、「エンジニア採用が難しいと企業が悩んでいる、だからエンジニアにとっては売り手市場なのだ」といくら説明しても、自分自身の能力にイマイチ自信が持てない、といった様子でした。 しかし、求人倍率などのデータを見れば、転職市場にエンジニアが足りていないのは一目瞭然です。私自身がプロデュースしているCodeIQへも、企業の採用担当者たちからの期待が高いことからも明らかなのですが。 本連載を読んでいる皆さんの中にも「自分の能力に絶対の自信がある」という人は、それほど多くないのかもしれません。しかし、それは同時に、自分の能力を客観的にアセスメント（評価）する機会に恵まれてい
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2016/05/17/20160510please-dont-learn-to-code/
【後編】デザインできるプログラマの育てかた〜「デザインメンター制度」のキモは理由で納得！
【中編】プログラミングとデザイン、やっていることはわりと同じ〜「デザインは感覚じゃない」
なぜプログラミング言語のように英語を習得できないのか？──カーネルハッカー・小崎資広（8） | サイボウズ式
