島根県仁多郡奥出雲町にある「森田醤油」のこだわり抜いた醤油作りへの情熱がすごかった
11/5〜6の２日間は島根県仁多郡奥出雲町で開発合宿を行いました。 (合宿の内容については別途報告したいと思います) 今回は合宿中に見学させていただいた森田醤油さんの醤油作りへのこだわりがあまりにもすごくて、 形は違えど同じ物作りをしている私としては紹介せずにはいられなくなりました。
- 使っている大豆は全て国産(島根が2/3、残りは広島など近くの県)
- 遺伝子組み替えした大豆は一切使っていない
- 添加物、化学調味料も一切使っていない
- 昔ながらの製法を使って、自然の状態を生かした醤油作りをずっと続けている
こういった昔ながらのやり方を続けているメーカーは全国でも1割程度しかなくなってしまったようで、 価格や効率化のためにこれまでの手法をやめるメーカーも多いようです。 ですが森田社長は周りの方から変人と言われるくらい(何度もおっしゃっていましたw) 徹底して安全かつおいしい醤油を作り出すために日々努力されているようでした。 そして昔ながらの製法は続けられていますが、その中から日々改善をされているようです。 その他にもたくさん醤油作りについて話をしていただきましたが、とても楽しい時間でした。
確かに現在大手メーカーによって作られている調味料は化学調味料などを使用して 安くて美味しくなるように調整されています。 しかし化学調味料はアミノ酸とひとくくりにまとめられたり、表記の必要のないものについてはラベルに明記されることはありません。 私自身も化学調味料の味になれてしまって、昔ながらの本当の醤油の味がどういうものかよく分からなくなってました。
更に大手メーカーの商品は大量生産により安く商品が提供されますが、 何でもかんでも効率化によって短時間に安く仕上げればよいというものではないはずです。 効率化という名の元に体に有害なものが含まれていいはずがありません。
こういったことを考えているうちにソフトウェア開発が抱える問題点と同じような問題が、 他の業種でも起こっているんだなぁとしみじみ思いました。 (効率化という名のもとに、不具合だらけだったり仕様的に全然使えないシステムを作っていいはずがない) 今回の見学はとてもいい機会になりました。 私ができる第一歩は価格は一旦置いておいて、まず食べる物をちゃんと選択することで本物の商品が残るようにしていく事だと思いました。
森田醤油の商品はインターネットでも購入できますので、 是非一度お試しください。
1日でJavaScriptを理解するために「パーフェクトJavaScript」を読んでみた
ここ数年アプリの仕事ばかりやってて、Web周りの知識が乏しくなりつつあったんですが、仕事で必要になりそうなこともあり重い腰を上げました。 ホント久々に丸１日好きにできる時間を持てたので、どうやって学ぶかいろいろ考えたんですが、 結局会社にあった「パーフェクトJavaScript」をひたすら読むことに。
「オライリーのJavaScript 第6版」が一番よさそうでしたが、ボリュームが840ページと分厚いので今回は断念。
結局part3までを読むのが精一杯でしたが、ここまで読んだ感想としてはなかなかの良書だと思います。 Javaとの比較をしながらの説明がJavaをよく知っている自分からすると理解しやすく助かりました。 2011年出版の本ですが、言語仕様についてはECMAScript 第5版の説明が中心でJavaScriptの独自拡張については別途説明をする形をとっており、 今時のブラウザならほぼサポートしてるので安心して読めました。
各ブラウザの対応状況はこちらを参照。
http://kangax.github.io/compat-table/es5/
本書を読んでJavaScriptの言語仕様で気になった部分はこんな感じでした
- 関数型プログラミングをサポートしてるけど、再帰処理はパフォーマンスの観点から使用することを勧めていなかった・・・
- undefined型は潜在的なバグを生む可能性が高そうだしなんとかならないか？
- thisの扱いを間違えるとハマりそう
- 存在しないプロパティ名を指定して値を代入するだけでプロパティが追加できるのはすごい
- アクセス修飾子(private, public)がない
- 名前空間をサポートしてないので、クロージャ使って隠蔽するなどの対応が必要でなんだか面倒
- アクセッサはあるらしい(これもクロージャで隠蔽する必要あり)
再帰処理の最適化については気になったのでググってみるとECMAScript 第6版からサポートしてるようでした。
http://qiita.com/pebblip/items/cf8d3230969b2f6b3132
JavaScriptのガベージコレクションがどうなってるのかも興味あったのですが、すでにお腹いっぱいなので別の機会に。
継承の仕方も一つじゃなくていくつか方法あったりと何かと自由度高いですが、言語レベルで規定されてる方が迷わなくて個人的にはありがたい・・・。
最後に正直１日で理解って厳しいけど、それくらいの気概でいくと時間の使い方とか意識するし、最短で理解する努力もできるのでオススメです。 (ようはやる気の問題かも)
島根に移住してエンジニアとして働くメリット＆デメリット
気が付けばあっという間に島根(松江)に移住して３ヶ月が立ちました。 せっかくですので、こちらで働き始めて自分が感じた島根に移住して働くことのメリット＆デメリットを書いてみます。
メリット
- 雑音が入りにくくプログラミングに集中できる環境になった(個人的にすごくうれしい)
- 勉強会などが少ない分、刺激は少ないがその分本来やるべき仕事に集中できる
- 流行とか最新の情報をひたすら追っかる必要に迫られなくなった分、純粋に興味のある分野の勉強をできるようになった
- 首都圏と比べると遊ぶところが少ない分、仕事に集中できる
- 松江駅からならバスで30分程度で出雲空港まで行けるので、仕事で東京へ行く際も移動が楽 www.ichibata.co.jp
- 物価が安いので、生活しやすい
- 家賃安いし、食材も全般的に安くてうまい
デメリット
- 勉強会などが少ないので最新の情報を気軽にキャッチアップする機会が減った
- 情報が周りから自然に入ってきにくくなったので、自分で頑張ってアンテナをはる必要がある
- 東京の仕事が多いので自分だけでなく、一緒に仕事をするメンバーもリモートワークに慣れていないとつらい
- 社内のリモートワークをする体制が十分ではないので課題がある
- 音声が聞き取れないとかそういう細かい部分が結構ストレスになる
- 人が少ない分仕事のジャンルも少ないので、仕事の幅が広がりにくい
- 車はほぼ必須といえる
と上記のようにまとめてみましたが、自分にとって島根で働くという選択はめっちゃ正解でした。 常に最新の技術を追わないといけない不安から抜け出すことができて、 これからどうすべきか？という本質な部分についてちゃんと考えるきっかけにもなりました。 あと私的には妻の実家が近くなった分、子育ての負担が減って純粋に仕事に集中できるようになったのもでかいです。
ごっそり環境を変えることができるという意味でも移住という選択肢はいいなぁと感じます。
東京の方がたくさんの刺激があって楽しいし、田舎はつまらないなんて思ってる人には ぜひ本当にそうなのか？と振りかってみてほしいです。 何が楽しいかなんて実際やってみないと分からないですし、無いなら作ろうと思える気概がある人なら絶対大丈夫です。
私のように県外の方で島根で働きたいというエンジニアの方は是非弊社の島根事業所にお越しください。 ご連絡さえいただければ見学はいつでも大丈夫です！ もちろん地元の方でも大歓迎ですのでよろしくお願い致します！
株式会社はてなを退職して島根に移住しました
６月に退職してそれと同時に島根に移住しました。 移住するにあたっての決定打となったのは子育てを妻の実家の近くでしたいということだったんですが、 僕自身も広島の片田舎出身ということもあり過疎が進むような地域でいかに働いていくかということに非常に興味がありました。 そもそも東京に全てが集中してしまい、地方との格差が広がるばかりの状況ですが リモートワークを含め場所を選ばない働き方の選択肢が広がってきています。 そんな状況の中で今なら地方からでももっと面白い仕事ができるのではないかという可能性にかけてみようと思った次第です。
これまでを振り返ってみるとサラリーマンやってフリーランスやってまたサラリーマンに戻って転職みたいな側から見ると心配されそうな生き方ではありますが、自分の中には一本の道があってその道をちゃんと前進しています。
ちなみに島根ではすでにRubyを使ったまちおこしをやってますが、 僕が得意なiOSの開発でも何か違った貢献ができないかと考えたりしてます。
退職してから改めて思うのは、はてなという会社の文化は本当にすごかったなぁということです。 エンジニアの技術や仕事に対するスピード感もですが みんながいかに働きやすい環境を作るかというところをちゃんと考え、いい方法があればすぐに実践するというスピード感も関心するばかりでした。 こういったことを学ばせてもらったことに感謝しつつ、新たな場所でそれらの経験を活かしていくつもりです。
７月からは株式会社ソニックムーブの島根事業所で働いております。 本社は東京なのですが昨年11月に島根事業所を新設したばかりで、僕は島根では６人目のメンバーとしてジョインしました。 おそらく島根では数少ないiOSやAndroidの開発も手がける会社であり、 地元のエンジニアの方々と一緒に島根をもっと盛り上げていきたいです。
もし弊社、島根事業所の採用について興味のある方は是非こちらを見てみてください。 http://www.sonicmoov.com/recruit/shimane/
島根は思った以上に住みやすく特に松江はとてもお気に入りの場所です。 今後はこのブログにも島根アピールを書いていく予定ですので、何卒よろしくお願いします！
アプリ開発者なら書籍「Web API: The Good Parts」は読んでおくべき
最近のアプリ開発においてクライアントサイドだけで完結するようなものはかなり少なくなってきたと思います。 おそらく何らかのAPIを直接もしくはSDK経由で呼び出すことがほとんどではないでしょうか。 そういった背景がある以上、すぐれたWeb APIがどうあるべきかというのはサーバサイドを担当するエンジニアだけでなく、 クライアントサイドを担当するエンジニアであっても知っておくべきでしょう。
今回読んだ「Web API: The Good Parts」はWeb APIを美しく設計する重要性、そして美しく設計するための指針を すでに公開されている様々なWebサービスのAPIを例に挙げながら、よりよい方法を提案してくれています。
個人的に印象に残っている内容をいくつか挙げておきます。
- エンドポイントの設計において重要な原則として「覚えやすく、どんな機能を持つURIなのかがひと目でわかる」こと
- RESTを意識しすぎない
- REST APIの設計レベルにはREST LEVEL3(HATEOASの概念の導入)まである
- 仕様が存在していないものに関してはデファクトスタンダードに従う
- レスポンスデータの設計において一部例外はあるがエンベロープは不要(理由としてはHTTPプロトコルというエンベロープがあるから)
- レスポンスデータはなるべくフラットにすべきだけど階層化したほうが絶対によい場合は階層化もあり
- エラー時は適切なステータスコードを返し、エラーの詳細はレスポンスボディにデータを入れる方法がクライアントの利便性が高い
- 配列データを返す場合、そのまま配列として返すよりオブジェクトに配列を包んでキーをつけて返す方がおすすめ
- HTTPの仕様をしっかり理解してなるべくそれを活用する（たとえば正しいステータスコードを返すなど）
- APIのバージョン管理はURIにバージョンを入れるタイプを推奨している(Twitter、Facebook、Tumblrなどが採用している)
Web APIを提供する側、使う側ともにすぐれた設計を共通認識として持つことで 開発の効率化につながりますし、Web APIを公開した際に変な設計をさらして恥をかくこともなくなりますw
正直もっと早く読んでおくべき本でした。
本書は全体で224ページと内容はコンパクトにまとまっており、 全てを読むのにさほど時間もかからないので是非一読してみることをお勧めします。
「SwiftではじめるUI設計&プログラミング」を読んだ
タイトルから期待して２ヶ月くらい前に購入したのをようやく読みました。 でもUI設計の話はほとんどなくて、 Auto Layout、Dynamic TypeやiOS8で新たに登場したインターフェイスの話がメインの内容で少し残念という印象。 ただこれからAuto Layoutを勉強したい人には、 インターフェイスビルダーだけでなくソースコードでの実装やVisual Format Language(VFL)にも触れていてよさそうな印象でした。
圧縮抵抗と内容ハギングについても分かりやすい説明があり、 個人的にはSize ClassesはConstraintだけでなくViewもインストールするかどうか選択できるという発見もあって個人的に助かりました。
その他には主要なビューやコントロールのリファレンスもあり、 これからアプリを作りたい人やAuto Layoutを初めて使う人なら読んでおいて損のない内容です。
これぞUI設計の教科書！みたいな書籍があればうれしいけど、これが正解みたいなのは無いんだろうなぁ。
それにしても久々にブログ書いた。
３日で作った「Facebookの未読メッセージを既読にせず読める」iPhoneアプリを公開しました！
タイトル通り３日間で作ってApp Storeに公開しました。
https://itunes.apple.com/jp/app/wei-dumessenja-facebookno/id949191056?mt=8&at=10l8JW&ct=hatenablog
これまで出したアプリの中でも開発期間は最短だと思います。 未読メッセンジャーというアプリでFacebookの新着メッセージを既読にすることなく未読のまま確認できるようになっています。 メッセージを確認して返信したい場合はアプリから直接Messengerアプリを起動できるので、メッセージの送信はMessengerから行ってください。
といういたってシンプルな内容ですが、実際使ってみると結構便利です。 実はアプリ自体は２、３ヶ月前に作っていて一人で使ってたんですが、便利なのでApp Storeに申請してみたらすんなり通ったという感じでした。
今回すぐに作れた理由の一つに JSQMessagesViewControllerを使ったのがあります。 このライブラリ使うことでチャット風の画面を作るのにほとんど時間かける必要がありませんでした。
申請してから審査通るまでは8日かかりました。 内容が内容だけに審査に入って3時間程度で審査は終わったようです。
ちなみにこのアプリ、利用できる期間が限られてましてFacebook API ver1.0が使用できるのが2015/4/30までと現状はなっています。 ですのでその期間を過ぎて実際にAPIが使えなくなった時点でアプリの公開もストップします。 ソースコードも公開予定なので準備ができ次第、App Storeのアプリ説明文にURLを掲載しておきます。
ちなみにこのアプリ12月22日のランキング見るとこんな感じでした。
ソーシャルネットワーク カテゴリのランキングで国内では357位と全くふるいませんが、Mongoliaでは35位でした。 (Mongoliaってどこにあるんでしょう・・・)
期間限定アプリではありますが、まだ時間がありますし既読疲れを防ぐためにも是非ご利用ください！
追記： Mongoliaはモンゴルでした。言われてみると確かにその通りですね。 honeybe さんありがとうございます。
