これまで、2度ほどレールを踏み外した。 1度目は就職を決めないまま院を出て、半年ばかりニートしてた時。 新卒カードもクソもないから、一流企業になんぞ入れる訳もなかった。 技術が身に付きそうなブラック企業を探して入り、3年間頑張って精神を病んだ代わりに、初歩的な技術力を手に入れた。 3年目にソリの合わないサディスト上司に当たってしまって、鬱で仕事を辞めて1年間ニートした。それが2度目。 1年間のニート生活で貯金を使い果たした代わりに精神の再建に成功し、1社目で手に入れた技術力をアピールして、そこそこグレーの企業に入った。 5年間頑張った。 今度は鬱らなかったが、会社の未来に見切りをつけてやめた。 社員数20人程度の中小企業で、5年経っても全く大きくならないなら、この先潰れる事はあっても大きく成長する事はないだろうと判断した。 退職金制度もなかったので、将来は任せられなかった。 年齢的に30代

Photo by Giorgio Trovato on Unsplash 年収800万は普通のエンジニアか否か。火種はいつものTwitterでしたが、いろんな意見が飛び交う興味深い話に各所でなっていたようですね。うーん、様式美。 ちなみに私の感覚だとこんな感じで、年収800万といえば、一般的なWEB開発においては複数プロジェクトの技術設計を行うアーキテクト級で、SIerではおそらく課長-部長級の給与になると思っております。年収800万はそういうラインです。 年収340 → 新卒 年収400 → 2年目(転職サイトゴロゴロ 年収500 → 普通のエンジニア 年収800 → アーキテクト、テックリード 年収1000 → PM、一部スタートアップエンジニア 私の感覚だとこれですね https://t.co/1bXuiPexRj — shinoyu (@shinoyu) February 9, 2

江草陽太 大阪府生まれ。ネットワーク、データベース、情報セキュリティのスペシャリスト。 洛星中学・高校のロボット研究部創立メンバー。ロボカップジュニアジャパンなどのロボコンに出場。 その後、大阪大学工学部電気電子情報工学科に進学。NHK大学ロボコンに出場。学生時代より個人事業としてシステム開発を行う。 2014年10月、新卒採用によりさくらインターネットに入社。「さくらのVPS」等のバックエンド開発を担当。IoTプラットフォーム「sakura.io」の開発責任者を担当し、サービス設計と開発を行う。 2016年7月、執行役員に就任。現在は、さくらインターネット全体の技術統括とコーポレートIT、情報セキュリティを担当。宅急便をSlackから発送できるサービスを開始するなど、コーポレートITに関わるDXのサービス化も行っている。 需要がなくならないエンジニアであり続けるために必要なスキルとは何で

TL;DR エラーハンドリングを行う目的 エラーハンドリングが適切に行われているとどう嬉しいか 1. エラーの発生原因が分かる 2. レスポンスステータスを型安全に出し分けることが可能になる どうエラーハンドリングを行うのか 実装方法 エラー型の定義で気を付けるべきポイント なぜanyhowを利用しないのか エラーハンドリングを行う上で持っている課題感 Drawer Growth グループ バックエンドエンジニアの中野です。今回は、私が所属するチームで gRPC API を開発する際に実践している Rust でのエラーハンドリングについて紹介していきます。 TL;DR エラーの発生原因がわかるようにエラー型を定義することが大切。 anyhow は使わずに自前のエラー型を定義して利用する。 エラーハンドリングを行う目的 そもそもなぜエラーハンドリングを行う必要があるのでしょうか。私が所属する

新卒でも中途入社でもいいんだけど、ものの数か月で辞めようと言う人は、そもそも何を考えて就職活動したのだろう。辞めるために就職したのではないだろう。入ってみたら当てが外れたということか。当てとは何だろう。就職活動にて合意したことについて入社してみたらそれが無かったということか。それが無い、と短期で判断して次々と就職活動したら、就職活動の中で、「ああこの人は続かないな」という悪い評価になってしまうのは間違いない。だから、何度も何度も転職を重ねるのは、ポジティブな事情でもない限り難しい。世にはプロジェクトのたびに会社を変える人もいるから例外もある。ただそうなるともはやフリーランスの世界である。フリーランスで働ける人など全体の中で言えば一握りなので、大多数の人は会社を何度も何度も変えるということはあまりしない。 大した経験もないのに、研修にケチをつけたり、現場の同僚に不満を持ったりと、自分の十メー

fumi 小学校1年生で初めてはんだ付けをしてから電子工作にハマり，今はハードウェア全般広くものづくりをしています。

研究室の学生用に用意した資料をここにも掲載しておきます。 PDFをslideshareからダウンロード出来るように公開しました。 卒修論生のみなさま、こんにちは、五味です。 卒修論(卒業論文・修士論文。異なる名称であってもそれに類する研究活動)において、これまでに立派な研究成果が上がっている、という前提で、よりよい研究発表をするための心得を紹介したいと思います。まずは本資料の構造を紹介しましょう。 まず、この資料はそもそもなにか、そしてどのように使うべきか。次は研究報告プレゼンテーション、特に卒修論発表というのが、そのものがどのような場であるか。次はメッセージとストーリー、すなわち報告全体の方針。スライド作成の原則、口頭発表の注意事項、そして最後に、本番の報告にあたっての心構え、です。 前書きではまずこの資料そのものについて。 本資料の目的はよりよい卒修論プレゼンテーションをしていただくこ

グーグルではたらくソフトウェアエンジニアです。 ご意見やご質問 あるいは Typo 等を見つけたときは GitHub Issues にお願いします。答えられる範囲でできるだけ答えますね。 この記事は不定期にアップデートしてできるだけ最新の状態を反映させるようにしていますが、いくつか内容が古い可能性があります。 連絡先は？ (Contact Info) Mail: mailto:hayato@google.com Google+: google.com/+HayatoIto GitHub: github.com/hayatoito Twitter (inactive): @hayatoito Twitter: @shadow_hayato IRC freenode: hayato テックリード (Tech Lead) Google における Tech Lead (テックリード) とはどのよう

あのとき助けていただいた増田です 昨日締切だったんだけど、無事に卒論提出できたよ 教授の添削も2回ぐらい受けられて、それなりに納得できるものは出せた 多分1年以上かけてても似たような出来になってたとは思う アドバイスくれた人が言ってたとおり、卒論無理って投稿した時点で完全に下準備ゼロってわけではなかった なんとなくこういう構成と結論にしようかな〜っていうとこまでは決まってて、それを肉付けする材料がゼロって状態ね だから、Google翻訳のカメラで見出しだけバーッて訳してって、ここ使えるなって思ったところを自分で訳して…って感じの作業(ここでめちゃくちゃ時間かかった)と、 それをなんとか章立てした枠に組み込むっていう作業だけで済んだんだ それでもかなりキツかったしもっと早くからやればよかったって思ったんだけど とにかくありがとう ブクマ？のコメントで応援してくれた人もありがとう、 そんなんで

意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

プログラミング出来る方法教える。 世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。 いや実際に "ない" というのはかなり語弊があるかもしれない。 しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。 普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。 例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。 しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。 そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と

概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きな食べ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ

HelloWorldやっても面白くねーんだよ！！ 皆さんこんにちは。 Google App Engine （GAE）でJavaがサポートされ、 PythonはスルーしたけどJavaならやりたい！でもJava未経験！ GAE/Jに手を出してみたけど、結局hello, world!のサンプルアプリを公開したまま 放置した状態になっていませんか？ 僕はそうです！ Java使えたら楽しいだろうなー Java覚えて仕事の案件こなしたいなー Java使えたらオブジェクト指向がもっとわかるだろうなー リア充へのあこがれ と、常々思っていつつも、Javaの最初の面倒臭さの前にいつもやる気喪失するんですよね。 HelloWorldひとつやるのにpublic static void main()書くなんて面倒臭すぎです コンパイルなんて面倒でやってられません eclipseの使い方憶えるのが面倒だし　ecli

あるブログが「写経には効果がない」という趣旨のことを書いていて「何を言ってるんだ？」と思いじっくり読んでみたら、彼の言う写経は「動くとわかってる10000行のコードを何も思考せず作業として書き写すこと」を指しているようだった。「そんなわけないじゃん」と笑ってから「もしかして世の中は写経をそういう捉えてるのか？」と不安になった。 写経は自分の中にモデルを作るための行動で、他のもっと効率のよい方法と比べた場合の利点は「自分の中にモデルがなくても使える」点に尽きる。全く知識ゼロでいきなり「自分で考えて書く」ができる人はいない。考えるための材料となる知識をまず脳内に運び込む、それが写経だ。 写経の過程で大事なことは以下の3つだ。 1: 早く学びが得られるように、なるべく小さいコードで実験し、すぐに結果を確認する。 2: 疑問に思ったこと、考えたこと、気づいたことを書き留める。どうしてこういう書き方

盛り上がっては下火になり、しばらくするとまた方々で語られるこの話題。 昨日、また注目エントリーやホットエントリーで下記の記事を見かけたので、この話題について書いてみます。 ■男のファッションが難しい理由について。 http://d.hatena.ne.jp/sukebeningen/20090114 ■ぼくが「そこそこ」の服を買う店 http://diary.lylyco.com/2009/01/post_253.html これまで書かれた記事や、はてなブックマークのコメントを読んだところ、「オックスフォード」「ヘリンボーン」といった素材の名称や、 「ボタンダウンシャツ」「カーゴパンツ」といった服の形状を表す名称は専門用語として認識されることが多いようなので、文字で説明するのではなく、お薦めの洋服を「無印良品」と「ユニクロ」に絞って、リンクを張って紹介します。 無難な服でも、サイズと色使い

この症状を克服できるかは分かりませんが、記憶に付いている負の感情をクリアにする方法はいくつかあります。 ●EFT（Emotional Freedom Techniques）＆TFT（Thought Field Therapy） 顔や体の経絡を指で軽くたたく「タッピング」という手法です。EFTはTFTを簡略化したものです。簡単なEFTから先に入るのもいいかもしれません。 ネガティブな感情の解放や心理的問題の改善、集中力を高めたり、感情のコントロールにも役立ちます。詳細はEFTやTFTの日本支部のサイトをご覧ください。 以下のサイトからEFTの無料のマニュアルがダウンロードできます。 http://www.eft-japan.com/free.html TFTの手順 http://www.jatft.org/stress-caring.html ●バッチフラワーエッセンス 花や草木などのエッセ

自分のなかにある、ぼんやりとした夢や希望の存在はわかっていても、あらためて「あなたは何をやりたいのか」「今後どうなりたいのか？」と尋ねられると、明確な答えを返せない……。そんな経験はありますか？ 筆者の場合は過去にそう聞かれたとき、ハッキリと答えることができませんでした。しかも、いまだに同じ状況だと気がついたのです。 そこで、いますぐ自分の “こうしたい” を探り、ハッキリさせてみることに。すると、自分の “こうしたい” がわかっただけでなく、成長のヒントが隠れている意外な場所もわかりました。その内容を詳しく説明しましょう。 【ライタープロフィール】 STUDY HACKER 編集部 「STUDY HACKER」は、これからの学びを考える、勉強法のハッキングメディアです。「STUDY SMART」をコンセプトに、2014年のサイトオープン以後、効率的な勉強法 / 記憶に残るノート術 / 脳