現時点では、はてブのお気に入りユーザーはTwitterのフォローよりも人数が少なくテック要素が濃いめという状態になっています。なので、タイムラインの流れの速さがTwitterに比べてゆっくりで、かつ内容は技術に関するものがほとんどというSNSを構成することができてます。 Twitterのフォロー人数が膨れ上がってるはてな民にオススメです。

Podcast

Podcastは仕事の行き帰り・仕事中・入浴中によく聴いてます。

rebuild.fm

mozaic.fm

購読しているのはこの2つです。

特にRebuild.fmはサポーターにもなってる大ファンです。好きなゲストはNさんとhigeponさんです。

この前試験的に放送されたPyData JP FMも面白かったです。日本でPython系のPodcastは少ないので、ぜひ継続開催してほしいと願ってます。

pydatatokyo.connpass.com

Github

GitHubのWatchやアクティビティも有益な情報なんですが、GitHubのタイムラインは観測しづらいUIなのが辛いです。

自分は@azuさんが作成したTwitterにGitHubの通知を流すlambdaファンクションをforkして利用してます。基本読み飛ばしてもいい情報なんで、Twitterで眺めるのがちょうどいい感じです。このアカウントをTweetDeckに追加してタイムラインが見れるようにしてます。

このlambdaの詳細は以下のエントリとリポジトリを参照してください。

GitHub - azu/github-to-twitter-lambda: Lambda bot that fetch own GitHub notifications/events and post to Twitter.

AWS lambdaでGitHubのアクティビティをTwitterで読む用に投稿する | Web Scratch

Qiita

Qiitaのタイムラインはフォローするタグのチューニングを正しく行えば有益な情報源になります。というのは、キャズムを超えたタグだとスパムみたいな有象無象の投稿によってタイムラインが埋まってしまうからです。

日本ではまだニッチで投稿数も多くない分野のタグのみをフォローしておくことが、Qiitaを嫌いにならないHowtoかなと思います。

自分が現時点でフォローしてるタグはこの6つでした。

rust
NativeScript
Bitcoin
vue.js
Angular2
Django

メルマガ

フロントエンド系のメルマガを2つ購読してます。

1週間分の注目記事がまとまってるのは、なにかとありがたいです。

社外Slack

社内Slackはもちろんですが、OSSやコミュニティのSlackにも参加するとよいです。自分がハマった場合に知見がある人に気軽に質問できたりしますし、他の人たちの技術的雑談をROMってるだけでも勉強になることが多いです。

まとめ

ここまでオンラインでの情報収集方法についてまとめてきました。

ただ、やはりオンラインよりも実際に人と話す・人から聞くというオフラインのほうが情報吸収率は高いと思ってます。機会があれば、どんどん外に行きたいところです。

あと意識したいのは、

黙ってコードを書く
自分からも発信する

ことを怠らないことですね。情報収集厨にならないように気をつけましょう！(自戒を込めて)

2016-12-20

2016年買ってよかったもの

この記事は、今年買ってよかったもの Advent Calendar 2016 20日目の記事になります。

www.adventar.org

エアーフロス

フィリップスソニッケアーエアーフロスウルトラ【歯間洗浄器】 HX8332/01

出版社/メーカー: PHILIPS(フィリップス)
発売日: 2015/07/01
メディア: ホーム&キッチン
この商品を含むブログ (2件) を見る

Rebuild.fmでmiyagawaさんとhigeponさんがお薦めしてたエアーフロス。
今年から矯正もはじめていて、ちょうど歯への意識も高まっていたので購入してみた。

rebuild.fm

フィリップスの取説によると、

歯ブラシ・歯間ブラシではケアしにくい「奥歯と奥歯の間」や、「歯並びの悪いところ」、「矯正器具やブリッジまわり」の歯垢・食べかすを除去してくれます。

らしいです。

使ってみた感想は

使用感が気持ちいい
届きにくいところを掃除できる
水が飛び散って綺麗に使うのがむずい
お値段は高い

ってところです。

おわりに

残念ながら、紹介できるのエアーフロスしかなかったです。
振り返ってみると、今年はガジェットにはお金使ってなかったみたい。

2017年はもうちょっとガジェットに投資したい。あと備忘録も兼ねて、買ったものは追記形式で書いてみます。

こんな感じを真似したいところ。

kannnonn.com

2016-12-20

まだ見ぬバグゼロを夢見て

はじめに

この記事は、ポエム Advent Calendar 2016 15日目の記事です。

過去

半年前に入社したときのSQUEEZEのコードは、いわゆる不吉な匂いに満ちていました。

重複したコード
長すぎるメソッド
巨大なクラス
長すぎるパラメータリスト

などなど。

ただスタートアップでスピード重視の開発をしていたので仕方なかったのだと思います。

現状

※ まだバグゼロは実現してません。少なからずバグは存在しています。

サービスをよりスケールさせていくために、それに耐えうる品質が求められています。バグゼロに向けて、現在次のような取り組みを行っています。

テストコードを書く
エラートラッキング
リリースサイクルを短くする
古いコードのリファクタリング・破棄
コーディングスタイルの統一
コードレビューの徹底

これらに関しては、バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログの記事をおおいに参考にしています。

ここではこういった取り組み以外に、バズゼロに向けて自分が大事にしているエンジニアの教訓を紹介します。

ボーイスカウトの規則
割れた窓の法則

ボーイスカウトの規則

http://d.hatena.ne.jp/asakichy/20100706/1278377244

アメリカのボーイスカウトにはシンプルな規則があります。「自分のいた場所は、そこを出て行くとき、来た時よりもきれいにしなければならない」というものです。

これは、実装作業にも当てはまります。コードは何度も洗練され続けなければならないからです。

割れ窓理論

http://d.hatena.ne.jp/asakichy/20101217

長期間修理されることのない割れた窓が１枚でもあると、ビルの住人に「投げやりな（ビルの状態など気にもかけないようになる）感覚」が植えつけられていきます。すると、次の窓が割れます。さらに、ゴミが撒き散らかるようになります。落書きもされるようになります。

このようにして、たった1枚の割れた窓から、建物全体に対する深刻な破損が起こり始めるのです。これが「割れ窓理論」です。

ソフトウェアの「割れた窓」、つまり「悪い設計」「間違った意志決定」「悪いコード」を放置してはいけません。ソフトウェアをごく短期間で腐敗させることになります。「割れた窓」が何枚かあるだけで、「残りのすべてのコードもガラクタなんだから、自分も適当に作業してしまえ」という考え方が忍び込みやすくなるのです。

伝えたいこと

「ボーイスカウトの規則」に則って、自分がさわったコードはリファクタリングして綺麗にする
「割れ窓理論」を忘れずに、悪いコードを見つけたら、見て見ぬ振りをしないですぐ対処する

つまりこういった日々の小さなカイゼンが、品質の継続的な向上につながっていくのだと。ここに銀の弾丸なんてものはない。

「忙しいからカイゼンできない？」ちがう、カイゼンしないから、忙しいのだ。 :: by and for engineers

このタイトル通り、カイゼンしないことの積み重ねは未来の自分の首を締めることになる。

カイゼンすべき割れ窓に気がついたら、言い訳せずに見て見ぬ振りをせずに真摯に向き合っていく姿勢こそが、バグゼロ実現のために必要なことなのだと信じています。

2016-12-20

Creative Commons Licenses に関するメモ書き

はじめに

この記事は、法律 Advent Calendar 2016 18日目の記事です。

Creative Commons 4.0

Creative Commons Licensesとは

クリエイティブ・コモンズ・ライセンスとは | クリエイティブ・コモンズ・ジャパンにある説明・画像を引用します。

CCライセンスとはインターネット時代のための新しい著作権ルールで、作品を公開する作者が「この条件を守れば私の作品を自由に使って構いません。」という意思表示をするためのツールです。

CCライセンスを利用することで、作者は著作権を保持したまま作品を自由に流通させることができ、受け手はライセンス条件の範囲内で再配布やリミックスなどをすることができます。

左側はいわゆる「All rights reserved」、著作権がある状態を表します。右側はパブリックドメインなどといわれる、保護期間が終了したり、権利が放棄されている状態です。

CCライセンスは先ほど示した左右の状態の中間に存在しており、“Some rights reserved”、限定された権利を主張するライセンス形式を提案しています。

ウェブが普及した世界において、作り手の権利が守られつつ、誰もが平等に作品を共有すること。

わたしたちは、このような中間領域を定義する方法で、作品の共有をスムーズにし、創造性豊かな環境を実現しようとしています。

Creative Commons Licensesの種類

クリエイティブ・コモンズは「表示（BY）」「非営利（NC）」「継承（SA）」「改変禁止（ND）」という4つの条件の組み合わせから6つのライセンスが存在します。

表示（BY）

Attribution
作品のクレジットを表示すること

非営利（NC）

NonCommercial
営利目的での利用をしないこと

継承（SA）

ShareAlike
元の作品と同じ組み合わせのCCライセンスで公開すること

改変禁止（ND）

NoDerivatives
元の作品を改変しないこと

ソフトウェアにクリエイティブ・コモンズ・ライセンスを付与することができますか？

FAQ　よくある質問と回答 | クリエイティブ・コモンズ・ジャパン

可能ですが、お勧めはできません。

クリエイティブ・コモンズ・ライセンスは、ソースコードとオブジェクトコードについては、適用の対象として考慮していないからです。Free Software Foundationによって公開されているライセンス（日本語参考訳）や、Open Source Initiativeがリストに挙げているライセンス（日本語参考訳）等、ソフトウェアに適したライセンスが既に他にありますので、そちらのご利用をご検討ください。これらのライセンスは、クリエイティブ・コモンズ・ライセンスと異なり、ソフトウェア専用のライセンスとして設計されています。

メモ書き

Creative Commonsはソフトウェアを考慮しておらずお薦めしていないので、GitHubのライセンス選択肢にも出てきていない。

Choose an open source license - Choose a LicenseではNon-Software Licensesにおいて、CC0-1.0・CC-BY-4.0・CC-BY-SA-4.0が紹介されている。

ソフトウェアだけでなくその他のコンテンツを含んだプロジェクトにおいては、該当箇所を明記した上で複数のライセンスを掲げることが推奨されている。

e.g. https://github.com/github/choosealicense.com#license

The content of this project itself is licensed under the Creative Commons Attribution 3.0 license, and the underlying source code used to format and display that content is licensed under the MIT license.

Software Licenses

ソフトウェアに関するライセンスについては、Choose a Licenseまたはその翻訳記事をあたるとよい。

2016-12-13

Pythonと私の想い出 #pyconjp

はじめに

この記事は、PyCon JP Advent Calendar 2016 13日目の記事です。

テーマ

「Pythonと私の想い出」

3日目の@rhoboroが書いたPythonと私の想い出 - PyCon JP Advent Calendar 2016の構成を真似て、自分の想い出をつらつら書いていこうと思います。

Pythonと私の想い出

想い出その1 - Pythonを知ったきっかけ -

前職のアライドアーキテクツで、関根さん(@checkpoint)がPythonの良さを社内で宣伝してたのがきっかけだと思います。PHP・Javaがメインの会社だったんで、あまり普及活動はうまくいってなかったですが...

当時なんでPythonに興味をもったかを思い出すと

The Zen of Python かっこいい
シンプルな構文美しい

-- ここまでは@rhoboroと同じ感想 --

次に

科学分野にも強い

というのは魅力的でした。数学が好きだったので。

最後は

関根さんがそこまで推すなら間違いなさそう

という気持ちが大きかったです。

そんな感じでPythonを学び始めました。

はじめは「みんなのPython 第3版」を買ってきて勉強してました。

ちなみに来週第4版が販売されるみたいですね。表紙がなんともファンキーになってます。

みんなのPython 第4版

作者: 柴田淳
出版社/メーカー: SBクリエイティブ
発売日: 2016/12/22
メディア: 単行本
この商品を含むブログを見る

想い出その2 - Pythonの好きなところ -

想い出その1で書いたポイントは変わらずいまでも好きです。ここではさらにPythonやり始めて好きになったことを紹介します。

PEPの存在
- 建設的な議論ができる仕組み
ドキュメント文化
- コミュニティのドキュメントに対する意識の高さ

あとはPythonが好きになるにつれて、PyCon JPのコミュニティに惹かれていきました。 2014に一般参加、2015からスタッフ参加ですが、次のようなことをいつもクールだなと感じてます。

上下関係がないフラットさ
属人性を嫌った情報のオープンさ
門戸を常に開いているウェルカムさ
やりたいことができる自由さ
無駄なことを嫌う効率のよさ

想い出その3 - これまでとこれから -

こんな感じでPythonにはまっていって、今年の4月には縁あって関根さんがCTOのSQUEEZEに転職もしました。まだまだ会社の規模も小さく大変ですが、やりがいを感じながら楽しく仕事してます。

Pythonの世界を教えてくれた関根さんへの恩返しという思いもあって、SQUEEZEの成功のために頑張りたいなと思う今日この頃です。

さいごに

ちょっと大袈裟になりましたが、以上「Pythonと私の想い出」をお送りしました。

明日の分はまだ埋まってないっぽいですね。だれか書いてくれるとうれしいなー д・)ﾁﾗｯ

www.adventar.org

2016-12-07

作業用BGMとしてのPerfume #prfm

はじめに

この記事はPerfume Advent Calendar 2016 6日目の記事です。

www.adventar.org

作業用BGMとしてのPerfume評価

2015・2016のPerfume Advent Calendar カジュアル勢の皆さんが作業用BGMとしての魅力を語ってくれました。

またRebuild.fmでmiyagawaさんも仕事中にPerfumeをよく聞いているとも話しています。

ここでは、Perfumeのどういったところが作業用BGMとして優れているのか分析してみました。

作業用BGMとしてのPerfume分析

集中の邪魔にならない感情を込めない歌い方
トランス状態へといざなうヤスタカの打ち込み
マシンの気持ちに寄り添っていけるテクノポップ
特に意味がなかったりするけどポジティブな歌詞
3人の人間性からもらえる元気と癒し

おわりに

参考: Perfume x 作業用BGM での検索結果

世のエンジニアの集中力と生産性を高めるPerfumeの魅力がもっと伝わっていけばいいなと期待しつつ、明日以降のPerfume Advent Calendarの参加者を待つことにしましょう！

2016-12-03

面接時における逆評価のすゝめ

はじめに

この記事は転職 Advent Calendar 2016 3日目の記事です。

自己紹介

社会人4年目 27歳
今年4月に転職
アライドアーキテクツ -> SQUEEZE

参考に4月の転職エントリを置いておきます。株式会社SQUEEZEにJoinしました

書くこと

今年の転職の振り返りでも書こうかなと思ったんですが、SQUEEZEではエンジニア全員が採用フローに参加しており転職してから採用側の気持ちもわかるようになったので、個人的な話よりももっと汎用的な面接Tipsを残しておこうと思います。

この面接Tipsはこの2つから出来ています。

僕が転職活動の時に何社か面接を受けて感じたこと
SQUEEZEが面接を通して大事にしていること

面接を通じての逆評価

面接は企業が候補者を評価する場でもあるけど、こちらからその企業を評価できる数少ない機会でもあります。候補者が面接の場でチェックしておくべき項目を挙げておきます。

技術的な質問があるか？

面接の場では企業の雰囲気・ビジネスにマッチするかどうかを中心に見られて、技術に関して質問されることがないところもあります。ポートフォリオやGitHubなどから技術に関しては問題なさそうと判断されて、そういった質問がない場合もありそうです。

自分は技術力に自信があるから問題ないと思っていても、そういった企業は以下のような可能性が高いので入社してから苦しむことになるでしょう。

技術に重きを置かないカルチャー
技術力が低い開発メンバー

同僚となる開発メンバーとの面接があるか？

人事担当者・マネージャー・CTO・役員といった人からの面接はあるけど、一緒に働くことになる同僚と会ったことないまま採用が決まっちゃうというケースもよく目にします。

入社してから実際に一緒に働くメンバーを知らないまま入社してしまうと、面接の時には感じなかったけど仕事を始めてから気づく違和感・ミスマッチが生まれる可能性があります。

小さい会社ならまだOKかもしれませんが、現場と採用が離れている企業ではえてして現場が必要としている/一緒に働きたいと思っているエンジニア像から乖離した採用が行われがちです。

仕事風景を見せてもらえるか？

働くことになるオフィスがどんな環境かは必ず確認しておいたほうがいいです。可能であれば、業務時間中のリアルな風景がいいです。いくら面接中の会話で福利厚生などについて聞いても、実際の作業環境が劣悪であれば意味がないです。この作業環境の良し悪しがエンジニアの生産性を大きく左右するので。

次のようなところを見ておくと、実際の現場の雰囲気がわかるかと思います。

1人あたりのスペース
デスクと椅子
PCスペック
エンジニアの服装
オフィスの騒々しさ

おわりに

この記事がこれから転職を考えている人の参考に少しでもなれば幸いです。

また転職の参考図書として一冊紹介しておきます。

エンジニアとして世界の最前線で働く選択肢　?渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

作者: 竜盛博
出版社/メーカー: 技術評論社
発売日: 2015/10/08
メディア: Kindle版
この商品を含むブログ (4件) を見る

この本は僕が転職活動していた時期にRebuild.fmでmiyagawaさんとNさんがおすすめしていたので読んでみましたが、国内でのキャリアチェンジでもなかなか参考になりました。

この記事で述べたような逆評価のことも書いてあります。個人的には、給料などの最終調整について書いてある「舞い上がったままオファーを受けるな」という章がぐっときました。