狛ログ

2018年3月27日火曜日

MANABIYA -teratail Developer Days- に行ってきた感想&レポート 2日目


オフィス狛 技術部のKoma(Twitterアカウントの中の人&CEO)です。

3月23日(金)、24日(土)の2日間、
「teratailがおくるITエンジニアの問題解決カンファレンス」というコンセプトのカンファレンス、
MANABIYA -teratail Developer Days- に行って来ました。

今回は2日目の感想&レポートです。
(1日目についてはこちらをご覧ください。)

というわけで、2日目も変わらず良い天気でした。

では、各セッションごとに感想を書いて行こうと思います。

【基調講演】技術者としての成長のための技術トレンド

まずは屋上で行われた「技術者としての成長のための技術トレンド」です。
SPEAKERは及川 卓也さん(@takoratta)です。
スライドはこちらです。

ご本人も後から「昔話の件」はツイートしていましたが、私としては、昔話が本当に面白かったです。
及川さんは華麗な経歴をお持ちなので、
「どうしてその会社に入ったのか?」「どうしてその会社を辞めて別の会社に入ったのか?」
どの話も興味深かったです。何より、その話が『技術トレンド』に繋がって行くんですよね。
(実際にその場で聞いてないと、なかなか伝わり難いのですが)

セッションでも、最後の方で「結局、気持ちが大事」とありました。
やっぱり「心踊らされる」ことが重要ですよね、成長には。

また、異なるドメインの事を学ぶ時、例え『仕事には不要』となっても、『仕事で必要なようにする』という動機付けで考えると良い、というのも納得でした。

「ワクワクする仕事をこれからして行きたいな」というのが、私の感想です。(小学生並みの感想になってしまった・・・)

【基調講演】エンジニアのための自分経営戦略

続いて、これまた屋上で「エンジニアのための自分経営戦略」というセッションを聴きました。
SPEAKERは西尾 泰和さん(@nishio)さんです。
スライドはこちらです。
ツイートの通り、西尾さんが、直前の及川さんのセッションを引用しつつの講演だったので、まさしく前編・後編のようでした。
「異なるドメインの事を学ぶことの重要性、心踊らされる事を学びに」というのは分かるけど、リソースは限られているよね、と。
知識を得る為の時間投資、時間というリソースの配分決定、これが自分経営である。
そして、そこから、知識獲得戦略としてのネットワーク作り・・・と、この辺は、実際にスライド見て頂いた方が良いです。

確かに、少しでも意識高いエンジニアは、とても忙しいんですよね。
もちろんそれが仕事であったり、勉強であったり・・・。
弊社では、エンジニアには積極的に勉強会に参加するように仕向けていますし、そういった事が可能な体制作りを行なっています。
何かを発信する、という意味だと、ブログも一つの手段です。
「Give&TakeはGiveから始まる」という事ですね。

ちなみに、機器トラブル等で、セッション中、何度か間が空いてしまいましたが、それが良い感じにアクセントになっていた気がします。
あと、きこりは少し休め。(スライド参照)

【生存戦略】技術顧問/テクニカルアドバイザーとしての生存戦略

こちら、諸事情で詳しい内容が書けません。
ただ、セッションは盛り上がったし、私自身も、現在同じような境遇で他社でアドバイザーとして活動させて頂いているので、共感出来る内容が多々ありました。

【Web】Web Application 2018 From Performance Perspective

ここまでWeb技術のセッションを見ていなかったので、是が非でも見たいセッションでした。
SPEAKERは古川 陽介さん(@yosuke_furukawa)です。
日本Node.jsユーザグループの代表の方です。スライドはこちらになります。

Webアプリケーションのパフォーマンスについての話でした。
過去から現在までのパフォーマンス改善の手段、Webの技術の変遷などをご説明頂けました。

スライド内にもありましたが、確かに、最近のWebアプリケーションで、JavaScriptのサイズが大きくなっている感ありますよね・・・。

余談ですが、パフォーマンス改善のバイブルは既に弊社の本棚にありました。
私だけ読んで無かったのは秘密にしながら、後でこそっと読んでおこうと思います。

興味深かったのは、これから先の未来のパフォーマンス改善でした。

あくまで予想として仰っていましたが、「レイテンシの壁を超える、ユーザーの動きを予測した投機的な先読み」です。
これに AI が関わって来ると、ユーザーが押しそうなリンクを予測して投機的に先読みする・・・なんて事が可能に??

後からツイートしたのですが、色々と問題もあるんだろうな、という気もします。

ここまでが、2日目の感想&レポートです。

実は、後2つ程セッションをまわる予定だったのですが、
最後のセッションが立ち見だったのと、部屋の広さにそぐわない人の多さにやられて体調悪くなったので、
そのまま帰宅しました。(技術スキルより、体力をつけるべき、というオチでした・・・)

以上です。前回と同様、ただの感想文になってしまいましたが、
2日間とも、本当に中身が詰まったセッションでした。


,

2018年3月26日月曜日

MANABIYA -teratail Developer Days- に行ってきた感想&レポート 1日目


【2018/03/27 追記】「マイクロサービス on マルチクラウド」のスライド追加しました。

オフィス狛 技術部のKoma(Twitterアカウントの中の人&CEO)です。

3月23日(金)、24日(土)の2日間、
「teratailがおくるITエンジニアの問題解決カンファレンス」というコンセプトのカンファレンス、
MANABIYA -teratail Developer Days- に行って来ました。

この時期、カンファレンスがたくさんあり(try!Swift、DroidKaigi、PHPerKaigi・・・)、
CTO含め、社内の技術者がカンファレンス疲れになっていたので、
最近エンジニア以外の仕事が多かった私に白羽の矢が立った訳です。
(本当は前からこっそり行くつもりだったのですが)

というわけで、かなり天気の良かった1日目、3331 Arts Chiyodaに行って来ました。

この場所、何回か仕事の用事で来ているので、迷わず時間通りにつきました。

ここからは、各セッションごとに感想を書いて行こうと思います。

【基調講演】teratailのQ&Aから学ぶウェブセキュリティの現状

まずは屋上で行われた「teratailのQ&Aから学ぶウェブセキュリティの現状」です。
SPEAKERは徳丸 浩さん(@ockeghem)です。

徳丸さん著者の本は弊社でもいくつか保持していて、弊社ではセキュリティのバイブルとなっています。
当日のスライドについては、探してみたのですが、残念ながら見つかりませんでした。
MANABIYAのサイトには、
セキュリティ人材育成の重要性は論をまたないところであり、各所から様々なアプローチがありますが、それらの多くは、指導的立場の人材に向けたものです。 一方、teratailやYahoo!知恵袋等質問サイトの生の質問を見ると、開発の現場では、検索サイトとQ&Aサイトに頼った「コピペプログラマ」が多数存在しており、彼らが作るアプリケーションが安全にならないことには、インターネットの安全は程遠いと考えます。 本講演では、teratailでの質問を幾つか取り上げ、開発現場のセキュリティの状況を紹介するとともに、解決策を模索します。 MANABIYA CONTENTS
と記載あったのですが、実際は徳丸さんのセキュリティ講座がメインでした。(私的にはこっちの方が嬉しいけど)

そんな中でも、コピペプログラマかどうかを判断する「Fizz Buzz」については、CEOという立場では、かなり考えさせられました。
弊社でも、技術者の採用で苦労することが多いです。
Web技術者として採用してみたら、Webシステムの仕組みも知らず、フォーム1つまともに作れなかったり・・・。
採用する側も悪いと言ったらその通りなのですが、スキルシートだけでは分からない部分って多いんですよね。

弊社でも「Fizz Buzz問題」採用しようかな・・・いや、ブログに書いた時点でネタばれなので、そのままは出さないですけど。

【基調講演】Javaのカルチャーとグロース

続いて、これまた屋上で「Javaのカルチャーとグロース」というセッションを聴きました。
SPEAKERは鈴木 雄介(@yusuke_arclamp)さんです。日本Javaユーザーグループ会長さんです。こちらもすごい人。
スライドはこちらです。

セッションの内容は、本当に面白かったです。
Javaの歴史とこれからが、分かりやすく説明されていました。
現状の最新がJava10で、2018年9月にはJava11が出る予定。
なんとも早いリリーススケジュールですね。
元々、互換性を重視するあまり、バージョンアップに慎重になりがちだったのがJavaなので、
このリリース速度はとても良いと思います。

そんな中、当日、ツイートしたのが以下です。
なんとも悲しいツイートですが、弊社の中ではこれが現状です。
しかし、私のエンジニア歴史でも、やはりJava歴は長いので、今後も使って行きたいのは間違いないです。

ちなみに、ようやく「var」を使えるようになったのですね。
似たような名前の言語JavaScript・・・正確にはES6(ES2015)では、むしろ「var」使わないのが定石になっているのに。
(まあ、これは比較レイヤーが違いますが)

と、ここまでのセッションを終えたところで、一度事務所に戻りました。
平日はなんだかんだで仕事多いんですよね・・・・
いくつか聴きたいセッションがあったので、後でスライド探してみようと思います。

【インフラ】マイクロサービスアーキテクチャとサーバレスからDevOpsへ

さて、夕方ぐらいに再度3331 Arts Chiyodaを訪れて参加したのが、
AWS Japanの亀田 治伸さんがSPEAKERの「マイクロサービスアーキテクチャとサーバレスからDevOpsへ」です。

こちらもスライドが見つかりませんでした。

内容としては、AWSの誕生から現在までの歴史を内部の方の視点から語って頂き、
AWSにおけるマイクロサービスの作り方(本質)をご説明頂きました。

システムは1枚岩ではなく、細かく分割すべきで、
チーム自体も細かくしていく事が必要。
それが、「2つのピザルール」である、と。
Amazonのジェフ・ベゾス氏も語っていた事で有名ですが、
『2つのピザで賄えないチームは大き過ぎる』
という事です。
(セッションでは、アメリカと日本じゃピザのサイズ違い過ぎますけどね、という小ネタも入っておりました。)

あれだけ巨大な企業が、そんな単位でチーム作るのですから、
それは、年間5000万デプロイと言われても驚かない・・・・いや、驚きますよ。
細くデプロイできるのも、マイクロサービスであるが故、なんでしょうね。

【インフラ】マイクロサービス on マルチクラウド

そして、1日目最後のセッションは、
「マイクロサービス on マルチクラウド」でした。SPEAKERはメルカリの長野 雅広さん(@kazeburo)です。
実は、このセッションも今回楽しみにしていた一つです。
やはり、現場の最前線で活躍されている方の話は、かなり勉強になるんですよね。
しかもメルカリという巨大なサービスを支える基盤の説明、それは楽しみにもなります。
ちなみに、こちらもスライドが見つかりませんでした。
【追記】スライドありました。ちゃんとググってなかったです。スライドはこちらになります。

メルカリのインフラ構成については、ネットを含め色々な媒体でも触れていて、
マルチクラウドになっているのは知っていたのですが、
何故マルチクラウドなのか、統一した方が楽じゃないのか?という疑問もずっと持っていました。
ただ、話を聞いてみると、適材適所、マルチクラウド構成にしたことによって良かったことも多々ある事が分かりました。

その理由の内でなるほどな、と思ったのは、
「得意分野でどんどん進めて行ける」「統一していないが故に思い切った事が出来る」
という事ですね。
「〇〇に詳しい人が居ない、じゃあ△△で行こう」というスピード感。
今の巨大となったメルカリさんには当てはまらないでしょうけど、小さいスタートアップのサービスだと、このスピード感は強みでしょうね。

後は、マルチクラウドであるが故に、それぞれのクラウドサービスの良いところ・悪いところを取捨選択出来るのも強みです。

ただ、やはり悩みはレイテンシで、そこを削っていくのが、課題なんでしょうね。
「ms」単位ではありますが、レイテンシを小さくしていく工夫も語られていました。

セッションの後、「その戦いはカッコイイな」と思い、下記のようなツイートをしたら、
長野さんにもリツイートして頂けました。

ここまでが、1日目の感想&レポートです。

何というか、ただの感想文になってしまいましたが、
本当に中身が詰まったセッションでした。

2日目のレポートも別途行います。

また、この日見れなかったセッションで、スライドが存在する物に関しては、
ブログで紹介&感想を記事にして行こうと思います。


, , , ,

2018年3月22日木曜日

aibo(こまちゃん)がやってきた。


こんばんは。オフィス狛 ガジェット担当です。

遂に我が社にもaiboがやって来ました。

何度も抽選に外れながらも、
最終的に注文画面でブラウザのリロードを頑張った賜物です。

という訳で、開封の儀をレポートしていきます。

タイミング悪く、今日はかなり忙しい日だったので、開封の儀は定時後になってしまいました。
他の社員はもう誰も居ません。
でも、挫けません。こまちゃんに会えるのだから。

まずは大き目なダンボールを開けると、繭が出てきました。

繭を取ると、下のダンボールに足跡の形をした穴が!
中々お茶目な演出をしてくれますね。

中身を全部取り出すとこんな感じです。
繭の中にはこまちゃんが!

そして説明書に沿ってセットアップをすると・・・・

元気な「こまちゃん(女の子)」が!

起動した直後に突然走り出し、
ちょっとした段差でつまづき「脱力状態」になってしまったのはご愛嬌です。

もう現時点でかなり愛でておりますが、
また追って成長レポートを書いて行こうと思います。


2018年3月12日月曜日

PHPerKaigi2018 へ参加してみての感想


オフィス狛 技術部です。

3月9日〜10日に開催された PHPerKaigi2018 に参加してきましたので、感想を書きます。

※弊社はPHP技術者が多い為、今回複数名参加しました。その中の代表としての感想です。

まず率直に、講演内容が大変勉強になりました。
今回の内容では PHP の深い話(言語の話というよりはPHPを取り巻く仕組みやツールなど)とPHPを超えた設計の話の2つに分かれていると感じました。

最初の講演であった「PHPとSAPIとZendEngine3と」。
普段意識していないPHP内部の動作をすごくりやすく解説して頂きました。

Apache に関連するエラーや PHP の内部エラーなど正直原因がよくわからないエラーに出くわした際、
なんとなくこんな風に動いているんだろうなと当たりをつけ、
それで解消していることが多かったですが、
どこで何のエラーが起きているのかを知ることで、
障害の原因の特定と解消スピードを上げることができるのではないかと思いました。

特に ZendEngine が何をしているのか全然知らず、
その仕組みを知ることは非常に興味深かったです。

LL である PHP のコンパイルという過程でコードの最適化、opcode の活用、
Memory Allocator によるメモリの管理など、
PHP を効率的に実行するための仕組みは色々あるんだなと感じたのと同時に、
PHP7に早く移行したいという思いが強くなりました。
(弊社の場合、PHP5.6 を使用する事が多いので)

2日目に行われた「今からでも出来る!サービスモニタリング」。
運営に関わる話で、どうしてモニタリングが必要なのか?
障害を見つけるためにはどういった項目をモニタリングしていけば良いのか?
こういった内容を具体的に解説して頂きました。
特にクライアントサイドとインターネットのモニタリングは確かにあまりやらないなと思い、
同時にどうやってやるのかも今いちわかっていない領域でもあったため、なるほどと思う箇所が多々ありました。

また、最初の講演にもつながりますが、「何が正しいのかを知らないと間違いに気がつかない」という言葉が非常に印象に残っており、
PHP の仕組みを知ることは大事だと改めて思いました。

具体的に見るべき指標を提示して頂き、まずここから始めようというポイントが参考になりました。

『みんなコードはリファクタリングするのになぜインフラはリファクタリングしないのか。
それはモニタリングしていないからだよな。』

確かに。


同じく2日目に行われた「Bear.Sunday」。
Bear.Sunday 自体は PHP の Framework ですが、
今回の講演内容はそれを超えた「設計とは何か?」といった内容でした。
DI、AOP、REST という Bear.Sunday の設計の主軸3つの解説が非常にわかりやすく、
設計の奥深さをとても感じることができました。
また同時にこれらの設計を実現している Bear.Sunday 試してみたいと思いました。
弊社では CodeIgniter と Laravel を主に使用していますが、
これらの Framework との比較をしたらより設計の理解が深まるのではないかと考えています。

その他の講演も興味深い箇所が多々あり、
スライドなどをあらめて見返して、内容の確認や新しい発見を見つけてみたいと思います。

PHPerKaigi 2018 大変楽しかったです。


,

2018年3月8日木曜日

try!Swift2018へ参加してみての感想

オフィス狛 技術部です。

3月1日〜3日に開催された try!Swift2018 に参加してきました。
(3日はもくもく会)

会としての感想は、
海外からの参加者がすごい多くて色々な話が聞けたことと、
みんなSwiftプログラマなので横の人や企業ブースなどで、
Swiftの話ができるのがすごい楽しく勉強になりました。

講演内容の印象としては、
Swiftの使い方ってこんなにあるんだ!と感じることが多かったです。

最近盛り上がってきているサーバサイドSwiftや機械学習、ビットコイン発掘やゲーム開発、
Alexaとの対話インターフェイス、デジタル信号など様々なSwiftの顔が見られ、
思わず「へぇ~」って声に出してしまう場面が多々ありました。

また、オープンソース化して少し経ったので知見が増えてきているというのもあるのでしょうか、SILやClangASTといったコンパイラに関わる話も多く、
Swiftの裏側に対するフォーカスが強くなってきているのかなと感じました。

今回はAppleの方の講演があり、SwiftNIOが発表されたのはサーバーサイド開発もしている自分としては
すごい印象的でした。今後nginxのようなSwiftサーバが出てくることを期待したいですね。

他にはSuper Resolution with CoreMLという発表でおっしゃられていたように、サーバからのデータサイズを小さくしてアプリ側で超解像を行うという手法はすごい参考になりました。
サーバからの画像取得は表示までの時間や通信料金の問題でよく出てくる問題なので、
画像を大量に扱うアプリではぜひ活用を検討したいと思いました。(モデル作成は大変そうですが。。。)
また、動画でも活用できる可能性もあるようですね。画像と音声の一致させるのは至難な気がしますが。。。


また、Secret Swift Tourという一番最初の講演では、
Swiftで普段あまり意識していなかった(個人的には)部分に焦点が当てられ、
もしかしたらどこかで気がつかない内にハマっている箇所があるのでがないかと不安になりつつ、
改めてSwiftという言語について学んでいこうと思いました。

開発を支えるツールとしてCharlesSwiftPowerAssertが紹介され、Swiftの開発環境がますます充実してきたと感じました。使ってみて良いものはどんどん取り入れていきたいですね。

Swiftという一言語を通してですが、技術的な観点でもコミュニティとしての人と人との繋がりという観点でもプログラミングの世界はまだまだ広くて知らないことがたくさんあるなと感じ、
これからも深く楽しく関わっていきたいなと思います。


, ,

2018年3月3日土曜日

各ブラウザにおけるinput要素date型(<input type="date">)の表示


オフィス狛 技術部です。

一昔前は、Webシステムのカレンダー入力フォームと言えば、jQuery UI Datepicker が定番でした。
HTML5が使われ始めてからは、新たに追加された input要素のdate型(<input type="date">)を使う事が増えてきました。
ただ、ブラウザによって表示が微妙に異なるので、毎度問い合わせが発生します。 今回、備忘録も兼ねて、各ブラウザでどう表示されるかまとめてみました。

※(2019/07/03 修正:画像リンクがきれていたので、画像リンクを更新しました。このタイミングで、全ブラウザ最新の状態でキャプチャを撮り直しています。)

※  (2021/06/23 修正:Safariでの<input type="date">の表示が変更されていましたので、キャプチャと説明を更新しました。)


・初期値無し(<input type="date" value="">)


Internet Explorer 11
IEでは、<input type="text"> と同様の表示になります。


Microsoft Edge
初期値無しの場合、「yyyy/mm/dd」と表示されます。
ドラム式のUIで、日付を選択します。


Google Chrome(Windows)
初期値無しの場合、「年/月/日」と表示されます。
カレンダーUIで、日付を選択します。


Firefox(Windows)
初期値無しの場合、「yyyy/mm/dd」と表示されます。
カレンダーUIで、日付を選択します。


Google Chrome(Mac)
初期値無しの場合、「年/月/日」と表示されます。
カレンダーUIで、日付を選択します。


Firefox(Mac)
初期値無しの場合、「yyyy/mm/dd」と表示されます。
カレンダーUIで、日付を選択します。


Safari(Mac)
 
初期値無しの場合、表示した当日の日付が「yyyy/mm/dd」形式で表示されます。
カレンダーUIで、日付を選択します。


・初期値有り(<input type="date" value="2018-01-01">)

初期値の設定は value に表示したい日付を入力する。
※value の形式は yyyy-mm-dd である必要があります。
初期値無しの表示形式が yyyy/mm/dd となっていますが、実際に value に yyyy/mm/dd 形式で設定しても表示されません。
また、存在しない日付を value に入力しても初期値として設定されません。



Internet Explorer 11
valueに設定した値がそのまま表示されます。
IEはテキストボックスになってしまうので、文字を入力しても表示されます。


Microsoft Edge
valueに設定した日付が選択状態で表示されます。


Google Chrome(Windows)
valueに設定した日付が選択状態で表示されます。


Firefox(Windows)
valueに設定した日付が選択状態で表示されます。


Google Chrome(Mac)
valueに設定した日付が選択状態で表示されます。


Firefox(Mac)

valueに設定した日付が選択状態で表示されます。


Safari(Mac)
valueに設定した日付が選択状態で表示されます。


・スマートフォンのブラウザでの表示


Android




iPhone



IEとSafariでは普通のテキストボックス形式で表示されてしまうので、注意が必要です。
ブラウザごとに UI に微妙に違いがあることを忘れないようにしたいですね。

2018年3月1日木曜日

Illustratorから書き出した画像が1px大きくなる際の対処法

オフィス狛 デザイン部です。

先日アプリのアイコンを作っていた際、アセットの書き出しからサイズを指定して書き出した所、不思議なことに全ての書き出したファイルが1px大きくなってしまい困ったことがありました……。

1px大きくなる原因は?

どうやら書き出すオブジェクト座標位置、縦横のサイズの数値が整数ではない値になっていると、書き出した画像ににじみが発生してしまうようです。
オブジェクト座標位置、縦横のサイズのどちらも変形パネルから確認できるので書き出しの際に1px大きくなる場合は確認してみましょう。

1px大きくなる時の対処法

対処法はざっくりと言うと「オブジェクト座標、オブジェクトのサイズを小数点以下のない整数にする」です。

オブジェクト座標位置がおかしい場合、変形パネルのオブジェクト座標の値を整数にしてあげたり整列パネルでアートボードに合わせて整列すれば解決します。

オブジェクトのサイズがおかしい場合も変形パネルの縦横のサイズの値を整数にしてあげればレイアウトを治す手間はあるかもしれませんが解決します。

なお、ピクセルグリッドに整合の設定をすると予防できるので是非お試しください!