三菱地所・サイモンは2018年6月7日、同社が運営するショッピングモール「プレミアム・アウトレット」の会員情報が流出した事件のセキュリティ会社による調査結果を明らかにした。登録済みの会員データのメールアドレスとパスワードに一致した24万件、メールアドレスのみ一致した3万件のほか、ユーザー認証時にエラーになったIDとパスワードの組み合わせも流出していると認めた。

グーグルはフェイスブックよりもずっと多くの個人情報を持っている。それなのに、フェイスブックのような厳しい批判にさらされていない（もちろん最近フェイスブックが批判されているのは、同社が不正に個人情報を流出させていたからなのだが）。 なにしろ私たちは、ありとあらゆる場面でグーグルを利用している。ネット検索はもとより、メール（Gmail）、カレンダー（グーグル・カレンダー）、地図（グーグル・マップ）、写真アルバム（グーグル・フォト）、動画投稿・閲覧（YouTube）、スマホのOS（アンドロイド）、そしてブラウザ（グーグルクローム）でもグーグルを使っている。一般的なフェイスブックのユーザーが投稿する赤ん坊の写真やコメントよりも、はるかに幅広い。 フェイスブックの12倍の情報量 それなのになぜ、グーグルの個人情報収集が批判されることは少ないのか。 この疑問に答えるため、私はまず、グーグルとフェイスブ

こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。

ふりかえりと反省 おはこんばんちは、中村改めいっせいです。 iCARE の開発チームでは、アジャイルな開発を目指すべく、スクラムの手法を積極的に取り入れています。 この前のスプリントレトロスペクティブ（スプリントふりかえり）をしている最中にあるメンバーが 「このスプリントの反省は〜」 と話してからふりかえりをしていました。 言葉のあやではあるかと思いますが、ここで自分はふと 「ふりかえりと反省は違うものなんだろうか？」 という疑問を持ちました。 アジャイルの「ふりかえり」とは？ アジャイルの文脈でいう「ふりかえり」は、 スプリントなりリリースだったりのある程度の期間で、 その期間の活動をふりかえって良かった点や改善すべき点をチームで議論・共有するものだと考えています。 プロジェクトの成功とチームの成長のために行う、とても前向きな活動だと思っています。 そもそも反省とはなんだろう？ 辞書を引

【シリコンバレー=白石武志】米マイクロソフト（MS）は4日、ソフト開発者が設計図（ソースコード）を公開・共有できるサイトを運営する米ギットハブを75億ドル（約8200億円）で買収すると発表した。MSは世界で約2800万人が利用するギットハブを取り込むことで、ソフト開発者向けのクラウドサービス事業を強化する。ギットハブは2008年の設立。スマートフォンの普及などとともに、無償公開し自由に改良でき

コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕

本日5/31づけでLeverages株式会社を退職しました。 ### はじめに 入社が2009年7月なので9年弱の在籍でした。入社面接で社長に3年でやめると告げるなどしましたが、自分の中では長いか短いかでいうとちょうどいいぐらいの期間じゃないかなと思っています。 まず、なによりお世話になった岩槻さんや諸先輩方、同僚各位には深く感謝しています。またLeveragesやteratailなどのサービスを通じて知り合った方々からも得難い経験をさせてもらったことを感謝します。 ### tl;dr - なんでやめたの？ - やめたのはなんとなく一周したかなという気持ち - 二週目に上に行くスパイラルを作らないとねずみ花火みたいになるなという気持ち - いわゆる"すごい人"と働いてみたかった - つぎなにするの？ - https://party-calendar.net/ こちらにアプリケーション(など

Quipper で Web Engineer 兼 Engineering Manager を務める @ohbarye です。スタディサプリの開発、その中でも特に合格特訓コースや決済周りの機能開発・保守が主な業務です。 弊社が開発するプロダクト「スタディサプリ」ではA/Bテストを用いたプロダクトの改善を行っています。Quipper の行動指針の一つに "Fact based" という言葉が含まれており、憶測や独断ではなく計測されたデータや事実に基づいて意思決定することが強く推奨されているためです。 このたびスタディサプリにおいて負債と考えられていた機能を「消してよいかどうか」、A/Bテストを通して判断しました。その際に用いた手法や結果、そこから見えたこと、考えたことをご紹介します。 プロダクトの負債とは プロダクトチームにとって負債と考えられていたのは「キャリア決済」という決済手段でした。そ

経緯 何故なのかまったくわからないんだけど、数ヶ月前からTwitter界隈で謎にタカられるようになった。 以下のようなハッシュタグまでできてもう収拾がつかない状態であった。 twitter.com これはこれでネタとしておもしろいし、僕もいろいろ勉強したいこともあるので逆に利用してやろうと思って、 なんとかさんの金で肉が食べたいというハッシュタグが流行ってるんですが、わりと真面目に、僕とペアプロしてくれたらお肉奢りますって言ったら何時間くらいでどれくらいの肉だったらやってくれる人いますかね？もちろん僕より対象言語とかフレームワークとかに精通してる人限定。— すえなみ＠すえなみチャンス？ (@a_suenami) 2017年12月21日 というツイートをしたのがもう半年くらい前。 ついに先日お声がけいただいた。 すえなみさんの奢りで、肉が食いたい。 Javaかつビジネスルール複雑系であれば、

こんにちは、技術部の長（@s_osa_）です。 先日、新卒の総合職・デザイナー向けに技術基礎研修を行ないました。 そこで研修をするにあたってどのようなことを考えて何をしたか、担当者の視点から書いてみようと思います。 なぜやるのか 研修を担当することになったとき、はじめに「なぜやるのか」「この研修の目的は何なのか」を考え直してみました。 ぼんやりとした「技術についても少しは知っておいてほしい」という気持ちはありましたが、研修内容を考えるにあたって目的を明確にする必要がありました。 研修を受けてもらうのは総合職・デザイナーの人たちです。 エンジニアに対して技術研修があるのは自然ですが、技術職ではない人たちに技術研修を受けてもらうのには然るべき理由があるはずです。 理由の言語化を試みたところ、「研修を受ける人たちは技術職ではないが、テクノロジーカンパニーの一員であることに変わりはない」というとこ

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

私信ですが今日、最終出社日なのでご連絡します。 以下の通りです。 From: はてな CRE To: オミカレ 副社長/CTO 関係各位に感謝を申し上げます。 ありがとうございました。 以上です。 よろしくお願いします。 なぜ はてな を辞めるのか まぁ１年ちょっとで出戻りなんでネガティブに見えがちなんだけどHatenaって会社にネガティブな感情は全然無くて感謝の気持ちでいっぱいです。 じゃあそれに勝るくらいオミカレが魅力的だったか？というとそれも違って、エンジニアとしてみて、プレイヤーとしてみて、Hatenaの方が魅力的だし、そもそも国内でも有数の優良企業です。 むしろオミカレはスタートアップだし課題が多い会社です。 僕はオミカレ起業当初のスターティングメンバー（CTO）なのである程度内情を知っている上で比較しても多くの人はHatenaを選ぶと思います。 それでも僕がオミカレを選んだのは

仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO

中国ハイテク企業のエンジニアで年俸1000万円以下はいない 2017年の採用市場では、中国の通信機器大手ファーウェイ（華為技術）が日本で大卒エンジニアを「初任給40万円」で募集して話題を集めた。厚生労働省の調査によれば日本の大卒初任給の平均は約20万円（17年）。日本企業の場合、エンジニアであろうと事務職であろうと初任給は基本的には変わらない。日本企業の平均初任給の約2倍で募集をかけた「ファーウェイショック」に「優秀な人材が流れてしまうのではないか」と戦々恐々の日本企業に対して、ファーウェイ・ジャパンの広報は「優秀な人材を採るためのグローバルスタンダード」だとすまし顔だ。 ファーウェイはスマホやルーターなどの通信端末、通信機器メーカーであり、スマホの販売台数、シェアはアップル、サムソンに次ぐ世界第3位。創業者が赤軍にいた、という理由で中国共産党との関係が深い、との嫌疑からアメリカ市場からは

技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて

PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ

皇室会議で2019年5月1日に元号を改正することが決まったと、2017年12月1日に新聞各紙が報道した。2018年中に新元号が公表されるという。政府は2017年12月8日に正式に閣議決定する見通し。元号の改正に伴うシステム修正が必要となる。 NTTデータは「元号改正による修正は限定的」（同社広報）とみる。システム内部で保持する西暦日付を和暦日付に変更するテーブルの修正が必要とする。 日立製作所は「平成から新元号への対応は比較的容易」（同社広報）と話す。新元号の公表から元号改正までの時期に余裕があるため、変更作業を計画的に実施できるほか、昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。