2. 自己紹介 大仲 能史 a.k.a. @onk 1982年12月18日生 33歳 ドリコム 10年目 (中途入社 2社目) 大学中退 → 派遣 → エージェント経由転職 趣味:問題解決とコードレビュー 肩書:スペシャリスト (アプリケーションエンジニア) フロントエンドからインフラまで
READMEを始め、ソフトウェアのドキュメント全般を書く技術というものをもっと洗練させていきたい。要件定義書のようなものだけでなく、開発方針や設計方針、API定義などなど。 これらのドキュメントをしっかりと整備するだけで、レビューの質も上がり新しい人が入ったときもスムーズに意識のズレなく開発ができる。はずだが、なかなかドキュメントの上手い書き方や管理の仕方というものは、コーディングのそれとは違い議論が活発ではない。 最近試してみたこと そういったドキュメントの中でも、"開発方針"や"設計思想"をどう残していくかということを考えている。それらを残しておくことで、コーディングのときも立ち戻る場所ができ、大きく道を踏み外さなくなる。 例えば、レイヤードアーキテクチャのようなものの"境界"をドキュメントにしていく。MVCでもクリーンアーキテクチャでも何でも良いけど、それらのアーキテクチャではそれぞ
インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d
「どうすれば英語を使えるようになれますか?」という相談を受けることが増えてきたので、今日会社で、「英語を使えるようにする方法」と題した勉強会を開催しました。 あくまで私の意見に過ぎないので、チラ裏扱いで、勉強会の内容を公開します。 1. 勉強会の目的 英語を勉強するきっかけを作ること 英語のスキルを向上させる方法を知り、実践できるようにすること 英語を使って、仕事で成果を出せるようにすること 2. 私の実績 「そもそも何でお前が教えるの?」という質問への回答です。 1) TOEIC 895点(あと5点が遠い) 2) Agile2014(アメリカ)で、英語で書いた論文が採択されて登壇しました。 ・採択された論文 3) DevOps Summit 2016(台湾)で、英語でキーノートスピーチを担当しました。 学習のポイント 私が日々実践していることを列挙します。 1. i英辞郎:ボキャブラリー
料理も、睡眠も、仕事もハック! GunosyのCTOが教える開発効率を上げるメソッド エンジニアなら誰もが効率よく開発を行いたいはず。でも、どうすれば?GunosyのCTOである松本勇気さんが、忙しさに負けず、開発効率を上げるための方法を教えてくれました。 開発支援・効率化ツールやChatOps等で業務ハックに余念のないエンジニアは多いでしょう。では、エンジニア視点で日常をハックすると、どのように生活が変化するのでしょうか。 株式会社GunosyのCTOの松本勇気さんは、若手ながらも10を超えるプロダクト、50人以上の開発メンバーを束ね、日々多忙に過ごしています。それだけでなく、業務で社内のインフラから機械学習基盤、広告配信、アプリ開発まで、全プロダクトの技術的な意思決定に携わりつつ、さらにはプライベートの時間もしっかり確保しているといいます。 松本さんが実践する、ライフハック術を綴っても
未再生エピソードがもうありません。 半年以内に配信があった中で、配信を楽しみにしているPodcastをいくつかリストアップしてみます。 目的は「もっとエピソード配信が増える」「もっとテック系Podcastが増える」です。 Rebuild.fm http://rebuild.fm/ 最近のテック系Podcastブームの先駆け。 テック系を通り越して既に別次元のエンターテイメントになっている。 なんでこんなに面白いのかわかりません。でも面白いんです。 mozaic.fm http://mozaic.fm/ Web技術。毎回濃くて勉強になります。 そのWeb技術をよく知らなかったらmozaic.fmその技術のエピソードを聞いてテンションを上げる方法をとったりします。 最近配信が止まっていますが、まだ凄いWeb技術がでてきたら配信されそうです。 engineer meeting podcast h
「ついカッとなって……」取り組んだ 開発者のための開発 で業務効率を改善させた話 ソフトウェアエンジニアの醍醐味は、華々しい働き方のみにあるものではありません。開発者のための開発など、地味かもしれないけど楽しくやりがいのある仕事について紹介します。 アプリケーションエンジニアの id:aereal です。はてなで働いています。 昨今は機械学習などが半ばバズワードと化し、「トレンドを追いかけなければソフトウェアエンジニアとして生き残れないのではないか」という漠然とした不安に襲われることはないでしょうか。 これという専門分野の技術を活かし、所属する企業やひいては社会へ貢献するというあり方は、技術職として華があり憧れを誘うものです。 しかしソフトウェアエンジニアの醍醐味はそういった華々しい働き方のみにあるものではなく、むしろその他の様々な分野にたくさん散りばめられていると筆者は考えます。 この記
日本には高い技術力を誇るメーカーがたくさん存在した。ソニー、パナソニック、富士通、日立、東芝、ダイキン、三菱重工、東レ..と数えきれないほどの優秀な技術力を誇る企業がある。 最近だとDeNA、サイバーエージェントといったWEB系の高い技術力をもつ優秀なエンジニアが所属する企業が増えた。しかし彼らの地位は高くない。今回はWEBエンジニアについて筆をとらせていただいた なぜ日本のWEBエンジニアは評価されないのか?日本のWEBエンジニアに限らず技術者は高い技術力を誇るにも関わらずなぜ評価されていないのか。評価されていないというのは、社内で、高い役職を得られず、調子にのった分からずやの営業部門が、指示する通りに動けよといったような半ば格下に見たような口調で指示を出されるなど相対的に待遇がよくないことを指す。加えて収入も高くないのが現状だろう。 高い技術力をもっていたとしても売上を作っている、お前
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
こんにちは、新卒2年目エンジニアの片岡です。 正社員転職メディア『ジョブセンスリンク』の開発を行っています。 http://job.j-sen.jpjob.j-sen.jp リブセンスには職種の『越境』文化が根付いています。 セールスに必要なデータは営業担当者が自らSQLを書いて用意します。 エンジニアがディレクター的な働きをして機能設計に深く関わることはリブセンスにおいて自然です。 このような環境下で、私は『開発者の立場から事業を推進する』という指針を持って他職種の方たちと協働しながら開発を行ってきました。 『事業を推進するエンジニアに求められるスキル・姿勢とは?』という自らに課した問いに対して、新卒としてリブセンスで2年間を過ごした経験からたどり着いた自分なりの答えを共有させていただきます。 事業を推進するエンジニアに求められるスキル・姿勢とは 1.危機感を持って技術を学び続ける 入社
この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視1年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 1年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると
渡辺です。 以前、JUnit実践入門を執筆した経験もあり、社内でもブログの文章が読みやすいと評価を受けています(内容はともかくw)。 折角なので、技術ブログを書くときに注意する点をまとめてみました。 はじめに結論を書く 一番大切なこと、それは結論を最初に書くことです。 エンジニアには時間ありません。 はじめに、何が言いたいか、何を解決するのか、そこを最初に書かないと、読んでて苦痛です。 回りくどかったり、話がブレブレだと最悪です。 「XXの時、解決するにはXXする」とか「XXについて一言でまとめるとXXです」など、最初にまとめを書きましょう。 見出しですべてを伝える意識を持つ 見出しは大切です。 見出しを追っていけば、内容が頭に入ってくるのがベストです。 「見出しをまとめてしまったら、本文に書くことなくなった(´・ω・`)」となれば完璧です。 まさに今、蛇足しか書いてません(笑)。 短い文
Photo by Maryland GovPics こんにちは。谷口です。 最近、企業の中途採用担当者の方に応募者の落選理由を聞くと「面接の逆質問で聞かれた内容でミスマッチを感じて落とした」と言われたことがありました。 面接では、つい「何を答えるか」ばかりに気をとられがちですが、実は逆質問で「何を聞かれたか」も、評価の対象になっています。 実際に「逆質問についてきちんと考えていなかったせいでマイナス評価につながってしまった……」という事例や、落選して後悔している応募者は少なくありません。 転職希望者の中には「逆質問タイムなんて面接終了後のおまけじゃないの?」と軽視してしまっている方も多いですが、実はおまけどころか、応募者の評価を左右する重要な時間なのです。 今回は、採用企業は逆質問をどう見ているのか?逆質問で聞くとよい例・よくない例や、逆質問の考え方についてお話ししたいと思います。 「逆質
後でコメント付けるから これは暫定的な方法、本番リリース時はこの方法で書かない 大体終わった。後小さい問題何個か残ってるだけ エンジニア:”十日は必要”。Boss:”五日でできる?”。エンジニア:”できる!” TODO 私の端末ではちゃんと動くのに これはテストする必要ない、絶対問題ないから そう、もうテストした 一行の修正だけ、他の処理に影響しない これは前からあった問題 追加10ウソ 次コード修正する時ユニットテスト書くよ 90%は終わった これは二分で解決できる そう、これは既知のBugだ 昨日はちゃんと動いてたのに そんなのありえない これはハードウェア/ネットワークの問題、私のコードと関係ない これはBugではなく、特性だ 私は今ドキュメント読んでる 私はサボってない、今ビルド中
Photo by Alex Graves 秋山です。 paizaでは主にプログラミングスキルチェック問題の作成を担当しているので、アルゴリズムについて調べることもよくあります。 というわけで今回はみんな大好き?な、数学的なアルゴリズムについて書いてみたいと思います。 プログラミングの勉強を始めたばかりの人から「アルゴリズムってどうやって考える&勉強するといいんですか?」と聞かれることもあるので、参考になればと思います。 ■数列のアルゴリズム(フィボナッチ数、黄金比) 数字が 1,2,3,4,5,6....100 というように、最初の1から順に1ずつ増えていくというのも、ある意味アルゴリズムにのっとった数列であると言えます。 もう少し複雑な数列になると、paizaラーニングのアルゴリズム入門編でも出てくる「フィボナッチ数列」という数列があります。数学が苦手な人でも聞いたことある言葉ではないで
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす http://japan.internet.com/busnews/20111013/8.html で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。 (2011/10/19 08:14)ありがたい誤訳の指摘をいただいたので3カ所修正。 Stevey の Google プラットフォームぶっちゃけ話 僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは(しかもその印象は日々強まるのだけれど)、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやも
当たり前の話かも知れないんですが、ちょっと書かせてください。 「頭がいい人は、難解なことでも分かりやすい言葉で説明出来る」みたいな信仰というか、都市伝説というか、聖闘士の伝承みたいなテキストが時折観測されるんですが、みなさんご存知でしょうか。 「頭がいい人 説明」とかでぐぐってみると、いろんなページが引っかかりますよね。 私、あれちょっと違うというか、色々誤解されてるなあ、と思っていまして。 正確には、「頭がいい人は、相手に説明をする目的と、相手にどこまで理解させる必要があるかを見極めることが上手い」というべきなんじゃないかなあ、と。そんな風に考えているのです。 昔、私が今とはまた違う職場にいた頃、一人「すごく説明が上手い人」が同じ部署にいました。彼のことを、仮にTさんと呼びます。 Tさんはエンジニアで、私よりも十年くらい先輩で、当時その職場に参加したばかりだった私がいたチームの、チームリ
オンライン動画学習サービスSchoo(スクー)で、「シリコンバレーで働くエンジニアと考える、これからのキャリア」と題した授業をさせていただきました。*1 シリコンバレーで働くエンジニアと考える、これからのキャリア 堤 修一 先生 - 無料動画学習|Schoo(スクー) 撮影を生放送で行い、視聴者参加型で行う授業でした。もちろんキャリアに正解なんてないし、キャリア観も人によって千差万別なので、僕が何かを教える、というよりは、まずは僕の経験や考えを共有して、あとはコメント・質疑応答ベースでみんなで考えていきましょう、的なコンセプトです。 講義 最初に30分(ホントは20分の予定だったのですが🙇🏻)の講義パートがありました。 講義資料はこちら。*2 自己紹介(僕のキャリアの変遷をざっと説明) 僕のキャリア観(理想) その実現のために意識していること4つ という3段構成です。 以下に簡単に抜粋
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く