注) 2016年辺りのまとめなので、新しめの本が入ってないのと、新しめの特定の技術の本は2020年現在だと通用しない本が多いです。 古典含め普遍的な物も多々あるので、現在も通用する物が多いはずです。リンク先が旧版の本も有るので注意。 Javaメインの会社の本棚です。あと、じつは洋書版もあります。
「あなたたちは技術力がない」 2019年を振り返って真っ先に思い浮かぶのは、普段一緒に働いてない人に、面と向かってこう言われたことだ。 みなさんはそんな経験あるだろうか? エンジニアの中でも特に優れたエンジニアのことをスーパーエンジニアという。スーパーエンジニアとは抜きん出て「技術力がある」エンジニアのことだ。 「技術力がある」って言葉、わかってるつもりでつい使っちゃうんだけど、みなさんはどうだろう? 例えば最近Twitterで話題になっていたこちらのツイート。 スーパーエンジニアが通った跡には誰もメンテできない超絶コードが残ったりするので、チームでパフォーマンス出せないスーパーエンジニアをありがたがるのって、ミーハーな経営者くらいしかそもそもいないのでは。— 大岡由佳『りあクト! 第3版』技術書典9までに刊行 (@oukayuka) 2019年12月25日 私の知っているスーパーエンジニ
id:Songmuです。現在は、Nature Remoというスマートリモコンや、Nature Remo Eというスマートエネルギーハブなど、電力系のIoT製品を開発しているNature株式会社で取締役CTOを務めています。 サーバーサイドからインフラにかけてのソフトウェアエンジニアリングが得意領域で、ISUCONというコンテストで3回優勝したり、Mackerelというクラウド監視SaaSのプロダクトマネージャーを務めたりもしていました。PerlやGoを中心に、多くのツールやライブラリをGitHubに上げています。 今でこそCTOという立場にありますが、私はあまり、他人のお手本になるような人生を送ってきていません。「将来こうなりたい」といったしっかりとした長期目標を立てることもなく、その場その場で適当に、時には真面目に生きてきた結果が現在です。うまくいったこととて、多分に生存バイアスがあり、
技術に関するカンファレンス等のイベントで使われるアンチハラスメントポリシーとは、技術系イベントなどでハラスメントに反対するというポリシーを明示するしくみで、最近では様々なカンファレンスで同様のポリシーが適用されています。私が運営に関わっているRubyKaigiというイベントもその一つです(ちなみにRubyKaigiでは2020年1月14日まで発表者募集中で、また現在スポンサーも募集中です)し、同じく運営に関わっている技術書典というイベントでも導入されています(ちなみに技術書典8サークル当選者の入金は12/22(日)本日締め切りなので、まだの方は今すぐ対応願います。そして技術書典8でもスポンサーを募集中です)。 とはいえ、アンチハラスメントポリシーは必ずしも正しく理解されているわけではないかもしれません。 まあ、正しいかどうかを私が判断するのは適切ではないかもしれませんが、私から見るとこれは
なぜ、私(CDN屋)は25年間無視していたIPv6に本気なのか? IPv6と私 私は、 20年ぐらい前まで、NTT研究所で働いており、IPv6組と呼ばれるグループに属していました。ただし、私自身は、IPv6をガン無視しつつ、CDN関連の研究開発を行っていました。この理由としては、IPv6の付加価値は「アドレス空間が広い」ぐらいしかなく、しかもIPv6はIPv4と互換性のない「新しいプロトコル」であり、「IPv6は下手すると普及しない夢物語」であると思っていたせいです。私は、NTT研究所を退社した後も、ネット&メディア業界に約20年席を置いてますが、IPv6に対する立ち位置(ガン無視)は大きく変わりませんでした。 なぜIPv6? しかし、ここ最近は、徐々に「IPv6やんなきゃ」という感じに変わってきました(先月は、人生で初めてIPv6サミットにも参加しました)。この理由として最大のものは:
この記事は Product Manager Advent Calendar 2019の18日目 です。 はじめに プロダクト作りにおける負債の種類 技術的負債 組織的負債 関係者的負債 思想的負債 負債の誕生 影響し合う負債の恐ろしさ 地道に負債を解きほぐしていく おわりに はじめに Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。 スタートアップの強みはストラテジーと実装の一致 早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。 逆に言うと、これらが一致していない場合、早さは生まれない。 正しい戦略が、組織や技術的負債のために実行されなければバツ。 逆に素晴らしいテクノロジーを扱えるチームがあったとしても、
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
その1. そもそもアイデアが思い浮かばない 遭遇確率 :★★★★☆ どんな壁?:いざWebサービスを作ろうとしても何もアイデアが思い浮かばない 解決策:身近な課題をひたすら探す サービスを作る上では何かを解決する系のアイデアであり、かつ自分が当事者であるとモチベーションも続きやすいです。 自分が普段ネットを使っていて不便だと思うこと、今使っているサービスの不満点、などなんでも良いのでとりあえず書き出してみましょう。 大体この中に自分の技術力でも解決できるような課題が存在します。 もし自分の中での課題が見つからないという場合は、日々Twitterのタイムラインで流れてくる身近な人が抱えている課題をピックアップしてアイデア化するのもありです。 回避策:しょぼいアイデアでも日々書き残していく いざサービスを作るというときにアイデアも出ないし身近な課題すら見つからない場合は、普段からアイデアを無理
Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント! 応募期間は2019/11/29~2019/12/31まで。詳細はこちらをご覧ください。 今すぐツイートするならこちら→ フォローもお忘れなく! 【IIJ 2019 TECHアドベントカレンダー 12/12(木)の記事です】 久しぶりに書きました。 どうもこんばんわ。九州支社で働くとみです。お久しぶりです。 実は2016年に一つ記事を投稿したのですが、実に3年半経過した今になってアドベントカレンダーの話が聞こえてきたので、久方ぶりに書いてみることにしました。 当時はこんな記事なんかを書いてたわけですが、この記事を書いてから3年間色々あったので、その中の一つを書いてみようかなと思います。 3年間で覚えたことを並べてみる 2016年当時はTHE ON-PREMISEと言われてもおかしくないような、どイ
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2019 10日目の記事です。 エンジニア組織の成長のために大切にしている2つの事柄 アカツキのエンジニア組織は2~3年かけて成長していく状態を目指しています。 そしてその成長のためには、情熱と技術の積み上げが大事である、と考えています。 1. 情熱という感情を大切に扱う アカツキでは、情熱を持って仕事をしている状態を称賛します。 というのも、その人の想いが込められたプロダクトは明らかに完成物のクオリティが高くなりますし、よりクオリティを上げるためのいかなる努力も惜しまなくなり、結果として人も組織も成長すると考えているからです。 情熱というのは大きな野望である必要はありません。 その人が心からやりたいと思っているものであれば、その情熱の炎に大きさは関係ありません。 個人として
こゆるぎ岬 @o_thiassos さいきん訳あって50~60代のシステムエンジニアやプログラマーを沢山面接しているんだけど、IT最初の世代の終末医療という感じで、非常にキビしい。技術者は技術だけでは引退まで生きては行けない。つまり「そういう人」たちが今、職を失い、職にありつけない。あと5年10年を生き残れない。キツい。 2019-12-04 19:50:41 こゆるぎ岬 @o_thiassos 高齢ITエンジニア浪人の経歴書を見ていると、約10年前くらいに大手メーカーやその下請をリストラされて、そこで使っていた限定的なスキルが通用するのがITしかなく、なんとか短~中期的な案件を渡り歩いて凌いでこれたけど、そろそろ本当に何も通用しなくなったって感じがある。 2019-12-04 22:34:46 こゆるぎ岬 @o_thiassos 「使えないオッサン」に、事実として、社会は容赦がない。また
はじめに 内部向けWikiとは? ありがちな問題 ググって出てくるから書かなくて良い? みんなに書いてもらうために 身内だけで通じる価値観を理解する 気軽に書ける雰囲気を作る 既にある記事の更新を躊躇わない 書くメリットを意識する あるべき内部Wikiの姿 今の悩み どのレベルから知識を共有するか 記事が増えすぎたときにどうなるのか 結局当人以外が記事を更新しない 最後に はじめに これはあくあたん工房アドベントカレンダー2019,2日目の記事です.技術の欠片もないポエムです. 他の記事はこちらからご覧頂けます. adventar.org 内部向けWikiとは? 例えばサークル・研究室・企業など,何らかの集団において,そのメンバーが様々な情報の共有に使用するドキュメンテーションツールを指しています.どういったツールを使っているかは,その集団の特性等に大きく左右されると思います.例えば オン
補足→ https://anond.hatelabo.jp/20191205212350 これは退職者アドベントカレンダー2019 (https://adventar.org/calendars/4051) 5日目の記事です。最初は自分のブログに書くつもりでしたが、書いてるうちにどこまで筆が滑っているのかわからなくなったので増田に投げることしました。そしたら余計にタガが外れたのはご愛嬌。 What's thisよく見かける「未経験からエンジニアへ!」ストーリーの、あまりなさそうなルートです。よくあるルートのほうはなぜかTwitterで報告して「○○系エンジニア」的な命名をしてから入社その後の動向が闇に葬られているのをかなりの確度で見かけますが、まあ、なんか、いろいろあるんでしょう。逆にそういう成功(?)体験の生存バイアスを強化する情報ばかりあふれていると情報として健全でないように感じます。
追記2 2019/12/04 21:00 こんなよくわからない記事をご覧いただきありがとうございます。 この事件を起こしたのは1年前で、Gitを使いはじめて1ヶ月のときに下記の事件を起こしてしまっていてとても混乱していたのを当時覚えています。 内容については、rmをしたかもしれないという記事に結果的になったかもしれませんが、私の記憶ではファイルを消した記憶はありません。 ただ、当時作業していたディレクトリもないのでコマンドを確認する手段がないため一番濃厚なrmをしたというのを今回の結論にしました。 曖昧さは申し訳ありません。 また、意見、感想、批評には全て目を通させております。伝わりにくい内容やわかった事実は適宜編集してできるだけ皆さんに伝わるよう善処いたしますのでどうぞよろしくお願いします。 追記2ここまで 追記 2019/12/04 13:00 1.本番環境でやらかしちゃった人 Adv
AWS、超高性能なクラウド基盤を実現するために独自開発した技術を説明。AWS re:Invent 2019 Amazon Web Services(AWS)のデベロッパー向け年次イベント「AWS re:Invent 2019」が、米ラスベガスで開催中です。 基調講演の前夜に行われたセッション「Monday Night Live」には、AWSグローバルインフラストラクチャ&カスタマサポート担当VP、Peter DeSantis氏が登壇。 そのためにどのような技術がAWSのインフラで使われているのかを説明しました。 独自のスイッチやNitro Controllerで高性能ネットワークを実現 超高速な処理をクラウド上で実現する上でカギとなる技術の1つ目は、広帯域で低レイテンシなネットワークの実現です。 AWSはそのためにネットワークスイッチ機器と、それらを制御するためのソフトウェアを独自に開発。
SmartHRの社長の宮田です。 この記事は SmartHR Advent Calendar 2019 3日目の記事です。 ソフトウェア開発にも役立つであろう「権限移譲」について書こうと思います。 胸を張って「これが得意です」と言えるものってそんなに無いのですが、CTOの芹澤さんから権限移譲だけはホメてもらえます。最近では「もしかしたら得意なのかも?」と思えるようになりました。そんな私が気をつけているポイントをまとめています。 権限移譲について学んだことはなく、独学です。そのため、すごーく当たり前のことしか書いてないかもしれませんし、逆に一般論からかけ離れている可能性があります。 あくまで、私が気をつけているポイントとして読んでいただければ。 いかに権限移譲してきたか? はじめに、私の権限移譲について紹介します。 半年でプロダクトにノータッチに 起業する前、私はWebディレクターとして仕事
ここ数年、技術カンファレンスと名のつくものが急速に増えてきたと感じていました。人と人が出会う場所が増えるのは大変素晴らしいことですが、これは同時に参加者の方の期待値や需要と供給のバランスがシフトするということであり、長期的にイベント運営を考える人間は向き合わないといけない命題であると思います。 歴史的に技術カンファレンスとは情報発信と交流の場でした。今も本質的な変化はないとは思いますが、そこに人を集めるための考え方が変わってきているのではないかと私は考えています(ここでは特に数百人〜数千人規模のカンファレンスをイメージしています)。 なおこれは DevRelcon で話そうと思っている内容の下書き的な内容であり、コミュニティ•カンファレンス運営 Advent Calendar 2019のエントリでもあります。Devrelconについてはちょっとネタバレでもありますが、当日までにはもっとまと
はじめに 当方フリーランスエンジニアで、現在転職(再就職)の予定は一切ありませんが、かなりたくさんの現場を経験した中で「Slackの活用方針は、その会社の技術への向き合い方を(ある程度)反映する」ってことが見えてきました。 もし今後僕が転職活動(再就職活動)をするなら「御社はどのようにSlackを活用していますか?」は必ず訊きます。絶対です。 例えば「高級な椅子やキーボードが支給されるか」っていうのも気になるところですが、それは転職面談だと聞きにくいですよね? それに比べると、"Slackの活用レベル" は訊きやすくて、かつ明確に色々な情報を教えてくれるな、と。 注意点 ここから便宜上Slack活用をレベルごとに分けて書いていきますが、例えば必ずしも「レベル2までしかSlackを活用していなければ、会社全体の技術水準はレベル2にすぎない」っていうことは無いっていうことをご理解ください。 正
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く