ハフポスト日本版ニュースエディター。 公衆衛生、ジェンダー、調査報道が関心領域。masako.kinkozan@huffpost.com

背景 postd.cc という記事がちょっと前にありました。 github.com Roadmap to becoming a web developer in 2018って最近のWeb技術のまとめみたいなもんもよく引き合いに出されます。 このまとめの中にフロントエンドのものありますが、これはフロントエンド技術自体のロードマップです。 これらの技術すべてに精通していればいいのかと言われるとそんな必要は全く無くて。 でも現場によって実際 フロントエンドエンジニアに求められているものはそれ以外にもたくさんあるんですよね。 会社によってマジでJavascriptプログラミングしかやらない人も、マークアップする人、デザインを作ってそれをCSSに落とす人、本当に一口にフロントエンドエンジニアと言っても幅広すぎ。 担当範囲が広すぎるフロントエンドエンジニアに関していろんな会社が募集してると思うんですが

ブロックチェーンは、技術としても未来像としても残念なものである2018/04/06 3ヶ月前、英語圏でバズったとある仮想通貨の記事を連続ツイートで翻訳し、何万人もの方に読んでいただきました。 翻訳ツイートをまとめた記事: 「誰もブロックチェーンを有効活用できていない」「仮想通貨のまともな使い道は通貨投機と違法取引だけ」仮想通貨ブロガー@reinabb3さんによる翻訳はこちら続編の翻訳今朝、原文の著者・Kai Stinchcombe氏から「記事の続編を書いた」と連絡が来たので、許可を得て全文翻訳しました。 題名は "Blockchain is not only crappy technology but a bad vision for the future"。 日本語にすると 「ブロックチェーンは、技術としても未来像としても残念なものである」になります。以下拙訳です。原文のリンクはこちら。

SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ

うちの上司のフィードバックって「なぞなぞ形式」なんですよ！ 中原先生、何とかしてくださいよ！ ・ ・ ・ 少し前のことになりますが、ある若手ビジネスパーソンのＡさんが、こんなボヤキをなさっていました。僕の専門は「人材開発」です。「何とかしてくださいよ」とのＡさんからのご依頼に直接おこたえするのは難しいのですが（笑）、ぜひ、そういう「なぞなぞ形式の上司のフィードバック」がこの世から減り「成仏」することを心より願い、このブログでご紹介させていただこうと思います。 Ａさん曰く、「なぞなぞ形式のフィードバック」はこんな感じだそうです。 上司　「ねー、Ａさん、ちょっと時間、いい？」 Ａさん「はい」 上司　「なんで呼ばれたか、わかる？」 Ａさん「えっ？」 上司　「わかる？」 Ａさん「いえ・・・突然なので、すみません。わかりません」 上司　「そうか、わかんないか」 Ａさん「はい、すみません・・・なんでし

NASA創設50周年式典で公演したスティーブン・ウィリアム・ホーキング博士（2008年4月21日撮影）。Photo by NASA/Paul. E. Alers. イギリスの宇宙物理学者、スティーブン・ウィリアム・ホーキング元ケンブリッジ大教授（1942年1月8日～2018年3月14日）が亡くなりました。ホーキング博士は、次第に筋力が低下する筋萎縮性側索硬化症（ALS）を発症し、病気と戦いながら研究に取り組みました。しばしば「車椅子の宇宙物理学者」などとセンセーショナルに取り上げられるホーキング博士ですが、では彼の物理学への貢献はどのようなものだったのでしょうか。（腰が抜けるほど凄い業績です。） ホーキング、ホーキング放射を発見する ブラックホールは、強い重力のために光さえも脱出できない「物体」です。重力の物理学理論である相対性理論から、その存在が予想されます。 そんな奇妙な代物が、果たし

調査データや統計データを掲載するコラムを長く担当しているとIT業界が数字で見えてくる。ITサービス市場は2020年以降に「崖」が待っているとか、プライベートクラウドがパブリッククラウドを上回って成長するとか、仮想通貨の不正採掘を働くマルウエアが2017年下半期から急増しているとか、記者／編集者にとって「次」の企画を考えるには欠かせない材料だ。 市場の規模と成長率共に「すごい」と感じた調査がIoT（インターネット・オブ・シングズ）に関するものだ。数々あるが、直近でいえばIDC Japanが2018年3月14日に公表している。曰く、国内IoT市場におけるユーザー支出額、つまり市場規模は2017年実績が6兆2286億円。5年後の2022年まで年平均14.9％のペースで拡大し、2022年の市場規模は2017年比2倍の12兆4634億円に達するという。

IntelはCPUに内在する脆弱性「Spectre」「Meltdown」に対して、被害を緩和するための修正パッチのリリースを進めてきました。新たに公開されたリストには、第1世代CoreプロセッサーのCPUのパッチ提供ステータスが「停止」となっていたことから、「Intelは旧製品への対応を止めたのではないか？」と話題になっていましたが、Intelはそれを事実だと正式に認めました。 Microcode Revision Guidance (Apr 3, 2018) - microcode-update-guidance.pdf (PDFファイル)https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf Intel Will No Longer Issue Spectr

NTT データ数理システムでリサーチャーをしている大槻 (通称、けんちょん) です。 今回はソートについて記します。 0. はじめに データ構造とアルゴリズムを学ぶと一番最初に「線形探索」や「ソート」が出て来ます。これらのテーマは応用情報技術者試験などでも頻出のテーマであり、アルゴリズムの Hello World とも呼ぶべきものです。 特にソートは、 計算量の改善 ($O(n^2)$ から $O(n\log{n})$ へ) 分割統治法 ヒープ、バケットなどのデータ構造 乱択アルゴリズムの思想 といった様々なアルゴリズム技法を学ぶことができるため、大学の授業でも、アルゴリズム関連の入門書籍でも、何種類ものソートアルゴリズムが詳細に解説される傾向にあります。本記事でも、様々なソートアルゴリズムを一通り解説してみました。 しかしながら様々な種類のソートを勉強するのもよいが、「ソートの使い方」や

ずっとフリーでやっていたんだけど4月から会社員になってみてビックリしたわ。なんなんだこれ。 ちなみに大学時代からデザイナーやっていて、知り合いからの案件で食っていたんだけど、知り合い以外の案件がなかなか成約しないし、地雷案件も多いんで将来が不安になってインハウスのデザイナーになった。でも、外注の管理が主な仕事みたい。 いやー、びっくりした。会社員は非効率とは聞いていたけど、ここまでダラダラやっていたとは。 始業時間ぎりぎりにみんなぬぼーっとやってきて、まずはコーヒー淹れたりネットサーフィンしてたり。 仕事しながらお菓子を食べて近くの人と雑談しだす。雑談の合間に仕事しているみたい。 トイレに行く途中に見える喫煙所にいつもいるやつがいる。 会議も時間になったらぬるっと集まって、冗談言い合いながら進行していく。議題がなくなったらずっと雑談してる。なんだこれ？ ランチも食べ終わったらコーヒー飲んで

開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～ コードレビューによって解決される問題とは？そして、実際にチームでコードレビューを実施する上で気をつけるべきこととは？ソニックガーデンの取締役プログラマー西見公宏さんが、コードレビューのポイントを、実践に基づき解説します。 ITを活用して事業の課題を解決するサービス「納品のない受託開発」を提供する会社、ソニックガーデンの西見公宏（にしみ・まさひろ／@mah_lab）です。お客様の「バーチャルCTO」として、サービスの企画からシステムの開発・運用まで、日夜幅広く関わらせていただいております。 皆さんは普段、ソースコードをどのくらい読んでいるでしょうか？ 普段からソフトウェア開発をしている人であれば、何か問題が起こったときの原因調査のために他の人が書いたコードを読んだり、はたまた自分の書いたコードを読

(注：2017/04/08、いただいたフィードバックを元に翻訳を修正いたしました。 @liaoyuanw ) この記事は、私の著書 『Deep Learning with Python（Pythonを使ったディープラーニング）』 （Manning Publications刊)の第9章2部を編集したものです。現状のディープラーニングの限界とその将来に関する2つのシリーズ記事の一部です。 既にディープラーニングに深く親しんでいる人を対象にしています（例：著書の1章から8章を読んだ人）。読者に相当の予備知識があるものと想定して書かれたものです。 ディープラーニング：　幾何学的観察 ディープラーニングに関して何より驚かされるのは、そのシンプルさです。10年前は、機械認識の問題において、勾配降下法で訓練したシンプルなパラメトリックモデルを使い、これほど見事な結果に到達するなど誰も想像しませんでした。

フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR