私なりの「時間の使い方」のベースは、ソフトウェア・エンジニアとして、いくつものプロジェクトに関わってきた結果辿り着いた、「必ず締め切りは守る」仕事の仕方にある。

Photo by Peter Petrus こんにちは。谷口です。 他人の開発環境って気になりませんか?私は気になります。 誰かの作業を見ていて「何そのツール知らなかった」「えっそのコマンド便利そう」となったことありませんか? 自分以外のエンジニアは、自分の知らない便利な何かを使っているかもしれない。というか多分使っている。 というわけで、paizaの中のエンジニアたちにそれぞれの開発環境やこれがなくなったら開発できないというハードやソフトや便利な設定、毎日のように使っているコマンドなど、とにかく開発環境について聞きまくってきました。エンジニアの皆さんにとって新たな発見となる項目や参考になる部分があればと思います。 ちなみに弊社のPCは基本的に全員MacBook(3年ごとに買い替え可能)です。ディスプレイも自分の好きなものがあれば買ってもらえます。(だからPCとディスプレイは後から入った人
この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。誤り・修正などがありましたら、@iwashi86までご連絡いただけますと幸いです。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化
プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日本でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日本でも言及されても良いと思ったやつを3つ紹介。 Simple Made Easy Rich Hickey(Clojure言語の作者)による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊
私がAI(人工知能)や機械学習って難しいナーと感じるところは、数学の前提知識がある程度必要なところです。 GoogleからTensorflowが出たときに、私もいっちょやってみるかなんて思ったのですが、参考にした記事もなかなか難しくてあんまり理解できなかったのを覚えてます。途中まで理解出来てたのに、急に数式が出てきて「なるほどわからん!」ってなることが多かったですね。 「というかエンジニアなのに数学苦手なのw」とビックリされる方もいらっしゃると思いますが、エンジニアっつったって、今の御時世理系出身エンジニアばかりじゃないんです。でもエンジニア女子やってると自動でリケジョ扱いされるから面白いですね。 当面の目標としては、AIの中でも機械学習を学んでいきたいので(DeepLearningできるようになりたい!)、あると嬉しい数学の知識としては以下です。 線形代数 確率・統計 微分・積分 AIの
勉強をやり直したいと思っている大人はどれくらいいるだろう。 私は社会人になってから勉強をやり直したいと思ったクチで、実際に受験をし、この春から大学に通いはじめた。あまり無い例だと思うので、同じ志をもった人達の背中を押す意味もこめて、思うところを書いてみたい。 1. 仕事は楽しいかね? 私は高校を出た後しばらく、The NEET生活を満喫していた。程なくして、遊ぶ金が無くなったという酷い理由でアルバイトをはじめたのだが、これが存外に面白く、結局この仕事を続ける事になった。相性がよかったのだろうか、会社から拾ってもらい、やりがいを感じる仕事を与えてもらえるようになった。プレゼンや研修のコツ、お客さんとの交渉の仕方を覚え、M$Office、人材管理(なんて嫌な響き)のノウハウ、プログラミングを学び、この場所でゆっくり成長していこうというと決意のようなものも固まりかけていた。 しかし、あるとき急に
若者の成長曲線は半端なく、おじさんエンジニアは日々恐怖を覚えます。 出る杭はちゃんと打っておきましょう。 環境の弄りがいのあるツールを教えるEmacs, VIM, zsh, tmuxなど…設定のいじりがいのあるツールは理想の環境を追い求めても終わりはなく、コンフィグはどんどん膨れ上がるばかりです。 それらを「一流のプログラマは、一つの道具にこだわりとことん使い尽くすもんだぜ」とでも言って、ずっとDotfilesのリポジトリばかりいじるようになってくれれば、彼らがプログラミングに費やす時間は減るはずです。 バイナリアンにさせるいくらアプリケーションが作れても、低レイヤのことが分からないとダメだと刷り込みます。 「プログラムがどうやって起動するか分かってる? えっ、mainを書けばそれが呼ばれる? あのなぁ、_startというのがあってだな…」 無駄に低レイヤに詳しいおじさん力を活かして、あた
そういえば今日これらを読んでて d.hatena.ne.jp d.hatena.ne.jp その中で Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており... はぁ? 「海外では当たり前()なんですねw 海外ってどこですか? タンザニア? パフアニューギニア? 」などみたいなリアクションを取りつつ、んで、まぁ、フロントエンドに関して、書きたかったことがあって、丁度良いので書いてみる。 というのも、フロントエンドが「凄く変化が早い」「ついていくのに大変」「新しい!!すごい」「これからは○○フレームワーク」だとかそんないろいろな意見が見られて、なんというか違和感を感じてるので今回はそれについて書く。 フロントエンドは変化が早い? まずこれ。僕は普通に違和感を感じている。確かに、jsフレームワークやライブラリとしたら、jQuer
先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールやフレームワークを必要とする現状はおかしい」といった、状況批判の意見が多く集まりました。 Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります。 そのため、まさか「フロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれ
各所でプログラマー不足が叫ばれる昨今。にもかかわらず、企業で働くエンジニアの中には、勤め先の要請によって「開発業務(コーディング業務)」から身を引かねばならない人も少なくない。なぜ、このような矛盾が生まれるのか。エンジニアが「好きな開発」と「キャリア形成」をうまく両立させる方法はないのか?データ分析と著名人対談を通じて考える。 「約4割のエンジニアが、ある時期を境に開発業務(コーディング業務)から完全に足抜けしなければならないと回答」 「マネジャー以上の年収分布では、技術専門職より一般管理職の方が年収が高い傾向に」 弊誌が今年3月に行った【IT・Webエンジニア300人調査】では、勤務先のキャリアパスについてこのような現実が浮き彫りになった。 >> 「コードで食っていく」は何歳まで可能か?エンジニア300人調査で見えた理想と現実 エンジニアという職業を選んだ以上、何かを作る仕事をし続けたい
https://twitter.com/kozeni_shkt/status/709743397196541953 http://www.b-ch.com/ttl/index.php?ttl_c=467 照度センサーという事で最初arduinoが思い浮かんだのだけれど、一般のご家庭やオフィスにarduinoは無いと思うのでiOSでやった。使わなくなったiPadにアプリを入れてオフィスの出入口に置いておく運用イメージ。 設定した閾値をディスプレイの輝度(部屋の照度)が下回ったらGet Wildし始める。なお手を抜いてるので閾値以下で輝度が変化するたびにGet Wildされる。 // // ViewController.swift // gettlod // // Created by ouba on 2016/03/28. // Copyright © 2016年 oubakiou. All
もひとつ、ぼくの活動をスポンサードしていただいているプログラミング学習スクール「 TECH::CAMP 」のブログから、素敵なストーリーを共有させていただきます。 ほんと、こういう時代ですよ!ぼくが今高校生なら、彼女と同じ道を進んでいると思います。 森川恵美(もりかわえみ)さん 1998年生まれの17歳。日本の高校には4ヶ月のみ在学し、アメリカへ。留学先の高校を10ヶ月で飛び級卒業。 帰国後日本の高校には戻らず、 TECH::CAMP を受講。現在は総合マッチングサービス Seekle (シークル) のリリースに向けて起業準備中。 実兄の森川照太氏が起業家で、アジアの留学生を日本の教育機関につなぐためのプラットフォーム【ST Booking】を運営するHakodate Ventures Pte. Ltd.のCEOを務めている。 起業家の兄を見て感じたプログラミング学習の重要性 ──プログラ
これを一部でシェアしたのは2014年なので結構前ですが、エンジニアのキャリアパスを考えるにあたって参考になるかと思って公開します。あくまで個人的な体験談で会社の見解などとは関係ないということに注意してください。 -------- 入社日記念の無料マッサージクーポンのメールを受け取って気づいたんだけど、こないだで入社後7年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ そもそも最初は2007年にGoogle Japanのリクルーターからメールをもらったのがきっかけだった。Google Japanの知り合いから紹介で誘いがきて、「お、これは引き抜きってことかな?」と思ってよろこんで話を聞きに行ったのだった
個人的な記録なので、誰かが読むにはコンテキストが不明な部分も多いと思いますが振り返りとして。 東京で 4 ヶ月 なんということはなく、妻が埼玉で里帰り出産をすることになったので、本社がある東京に埼玉から通うことにさせてもらった感じです。この手の勤務地変更は会社でも初めてだったと思うのだけど、地方勤務者が本社に勤務地変更するということで受け入れてくれて助かりました。 リモートワーカーとしての私 リモートワーカーとして皆さんが浮かべるイメージは在宅で自由な時間でという感じだと思いますが、私の場合はリモートワーカーと呼ばれてるものの、実際は他にも勤務者が居る地方(と言っても山奥)のオフィスで東京と同じ勤務時間働いているので、どちらかというと支社とかで働いている人に近いと思います。 たぶん、場所が超山奥で開発・営業拠点的な意味は全く無い場所なので、リモートワーカーぽく扱われているのかも。 一方で、
重要 本記事の内容は2018年5月に公開されたMacTeX 2018に対応していません。MacTeX 2018を用いたインストールの方法は、Yusuke Teradaさんの記事をお勧めします。 0. はじめに 2015年10月に公開されたOS X 10.11 El Capitanでは、セキュリティの強化やフォント管理方式の変更に伴って、従来のTeXインストールの方法が通用しなくなりました(詳しくは寺田先生による説明をお読みください)。ここでは、El Capitan以降のmacOSにTeX環境をゼロから構築する方法を、備忘録を兼ねて書き留めておきます。 ここで対象とするのは新たにTeXを導入するEl Capitan / Sierraユーザーです。Yosemite以前からのTeX環境を残したままEl Capitan以降にアップデートした場合の対応はここでは説明しませんので、他のエントリー(ここ
プログラマ向けノートアプリQuiverが素晴らしい(Mac用アプリ)Markdownをサポートしたメモアプリは数多くありますが、技術系のメモやスニペットを書き溜めるのに適したものはそれほど多くありません。 個人的な要件としては、 データフォーマットがオープンで好みのクラウドサービスで同期できることMarkdown(GFM)を扱えてプレビューできることコードの取り扱いが簡単なこと(できればシンタクスハイライトも)ファイルを意識しないで使えること(ファイル名を考えたりしなくて良い。オートセーブされる)ノートブック、タグなどでノートを整理・分類できることぐらいなのですが、すべてを満たしたアプリをなかなか見つけられず、Day OneやUlysses、Kobitoなどを併用して凌いでいましたが、最近、知ったQuiverというアプリがこれらの要件をすべて満たしており、これに一本化することに。 あまりに
ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な
マルコフ連鎖による文章自動生成 ちょっと文章の自動生成に興味が湧いたので、試してみることにしました。まずは事前調査したところ、既にやっている例がたくさんみつかりました。記事末の参考リンクにまとめましたので興味ある方は参照ください。Deep Learningやマルコフ連鎖を使うのがトレンド(?)のようです。本当はDeep Learningでやってみたかったのですが、何度か環境変えてチャレンジしたのですが、悉くエラーが出て失敗したため(chainerのバージョンアップの影響?)、諦めてマルコフ連鎖で実現することにしました。マルコフ連鎖に関してはここでは詳細は説明しませんので、興味ある方は自分で調べてみて下さい。自分もちゃんと理解できませんでした。イメージ的には、元となる文章の文章の流れのようなものを解析して、その解析した流れを元に、ある単語から順番に連想ゲームのように単語を並べていって文章を生
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く