開発はコストです。早く終わるということは、その分コストを削れます。コストを削ることができればその分が利益になります。ビジネスの目的である利益に貢献しているので、これはとても価値のあることです。
バスより飛行機が高いのも早く目的地に着くからですね。食洗機や洗濯機をお金を出して買うのも、家事の時間が短縮されるからです。
ブラウザは何を使っていますか?世界のブラウザのシェアNo1はGoogle Chromeです。Chromeが1番速いからみんな使っているのです。
速いということはそれだけで価値があるのです。
]]>プログラミングの経験が浅い人は、難解なコードを書いたり、短い行数でコードを書けることがかっこいいと考えているかもしれませんが、完全に間違っています。シンプルに実装することは実は難しいのです。プログラムというものは、すぐに複雑になってしまうからです。複雑でかっこいいコードを書こうという考えがそもそもの間違いです。
この記事を読んでいるみなさんは、今後は簡単でシンプルな必要最小限のコードを書くという意識でコードを書いてください。
私はNode.jsのコミッターがトラディショナルなfor文を使ったコードを書いていることを見たことがあります。そのコードは、これ以上ないくらいシンプルなコードでした。
現在のプログラムの多くは、今後も多くの変更が入ります。そうであれば、完璧に動くことよりもメンテナンスがしやすいことが大切です。後々、悪い影響を及ぼすコードは複雑で難解なコードです。シンプルで意図が明快なコードが問題を起こすことはありません。
一般的な技術を有したエンジニアであれば誰でも理解できるコードを書いてください。
]]>テストカバレッジ100%は目指さない
以前、このようなツイートをしました。
マージ条件に作成したコードのテストカバレッジが100%であることというプロジェクトを見たことがあります
— しょーやん (@sinn_shoyan) July 28, 2019
テストカバレッジ100%に違和感を感じない人はもう少し勉強した方がいいですね。
テストカバレッジ100%を目指すとこのようになってしまいます。
テストカバレッジ100%を目指すとどうなるかを説明しましょう。 テストの目的がカバレッジを通すことになってしまい、意味のないテストが乱立します
— しょーやん (@sinn_shoyan) July 28, 2019
さらにテストの問題も発生します。
さらに、コードとテストコードが密結合になり、コードを少し変えるとテストが落ちるという状態になります。 リファクタリングする場合、テストコードも書き直しになります
— しょーやん (@sinn_shoyan) July 28, 2019
テストカバレッジの問題については次の記事に詳しく書いてあります。
全てのコードにコメントを書くのは馬鹿げていると感じる人は多いでしょう。全てのコードにテストを書くということも同じように考えるとどうでしょう。何事も過ぎたるは及ばざるが如しです。
]]>私はエンジニアとして12年目で、現在はエンジニアチームのリーダーとしてWebアプリケーションのシステムを開発しています。キャリアとしては、SIerで1年、ベンチャー企業で3年、300人程度の企業で5年、現在は6000人規模の会社でエンジニアとして働いています。
前提として、ここで話すことはアプリケーション設計に関する話しです。データベースの関数自体の使用を否定しているわけではありません。データベース固有の関数を使う前に少し考えてみましょうという話しです。まずは、データベース固有の関数を使うリスクについて説明します。
データベースには固有の関数が用意されています。MySQLだとDATE_FORMATやNOW、SUMといったような関数です。これらを利用するのは便利ですが、安易な利用はおすすめしません。相応の理由がない限りは避けるべきです。理由は、データベース固有の関数を利用すると移植性が失われてしまうからです。
多くの人はデータベースを変更することはほとんどないだろうと考えます。本当にそうでしょうか。
例えば、開発環境ではSQLite、プロダクション環境ではMySQLを使うということは特段珍しいことではありません。
トランザクション境界を分離できないようなインテグレーションテストを実行するときはどうでしょうか。
ユーザーの情報を取得するAPIのインテグレーションテストがあるとします。このテストをクリアするためには、事前にユーザーのデータをデータベースに登録しておくことが必要です。そうでなければユーザーのデータを検証することができません。
テスト用のデータベースを共有で利用していた場合、一時的に作成されたテストデータが他のテストに影響するようになるでしょう。この問題は複数のテストが同時に実行されるようなCI環境になると顕著に現れます。解決策の1つとしてプロダクション環境と同じデータベースが含まれたイメージを作成するという手がありますが、複雑なイメージファイルを作成することは、なるべくなら避けたいところです。
ロバート・C・マーティンは著書「Clean Architecture」で、データベースはあくまで道具の1つであり、アーキテクチャの中心になるものではないと言っています。データベースは家のドアノブのようなものであり、アーキテクチャ的にはどうでもよいのです。ドアノブに家の設計を合わせることはしないでしょう。データベースがドアノブのようなものであれば、データベースに依存しないようにアプリケーションを実装するのは当然のことのように思えます。
RailsやSpringのような現在のフレームワークは、データベースを抽象化して扱えるような仕組みを提供しています。多くの場合、それはORMとして提供されており、利用するドライバーの設定を変更するだけでデータベースを変更することが可能です。
アプリケーション設計の側面から考えると、データベース固有の関数は避けるべきです。データベース固有の関数を利用する必要が場合は、基本的なCRUDで同じことができないかを検討しましょう。さもなければ、たった1つのデータベース固有の関数のせいでアプリケーションの移植性は失われてしまいます。
多くのアプリケーションは基本的なCRUDで構築することが可能です。少しの手間を省くためにデータベース固有の関数(例えばMySQLのREPLACE)を利用することはデメリットの方が大きくなる可能性があります。よく見られるアンチパターンはNOWの多様です。時刻はアプリケーション側で取得できます。アプリケーション側で対応できるものはアプリケーションの機能で対応しましょう。
データベース固有の機能に頼った方がいい場合も存在します。例えば、位置情報を扱うような場合です。位置情報を扱う場合、PostgreSQLの拡張であるPostGISを利用した方が少ない労力で実装することができるでしょう。このように明確なアドバンテージがある場合はデータベース固有の機能を利用しない理由はありません。
]]>私はエンジニアとして12年目で、現在はエンジニアチームのリーダーとしてWebアプリケーションのシステムを開発しています。キャリアとしては、SIerで1年、ベンチャー企業で3年、300人程度の企業で5年、現在は6000人規模の会社でエンジニアとして働いています。
度々「相談」という言葉が耳に入ってきます。この「相談」という言葉について耳にするたびに「基準を作ればいいのに」と思います。今回は「相談」と「基準」について考えていきたいと思います。
はじめに私の周りで使われている「相談」について説明します。「相談」とは次のような意味で使われています。
なんらかの判断を行わないといけないとき、その判断の観点を他者に伺う、もしくはその判断が正しいのどうかを他者に伺う行為。
私は「相談」という言葉があまり好きではありません。それは、相談が引き起こすふるまいには次の問題点があるからです。
自分以外の誰かに相談するということは、次のようなタスクが必要になってきます。
これらは本質的な仕事ではなく、仕事のスピードを遅くするだけのタスクにすぎません。
多くの場合、なんらかの権利・権力を持っている他者に対して相談を行うことになると思います(なんらかの権利・権力を持っているので権力者と呼ぶことにします)。例えば、ある権力者はAと言いますが、他の権力者に聞いてみるとBと言います。このように権力者によって回答が異なる場合、現場は混乱します。
自身で意思決定ができない環境でプロフェッショナルとして仕事を行うことは困難です。
このように相談にはいくつかの問題があります。相談の問題が見えてきたところで、「基準」について説明します。
「基準」とは何かの判断を行うときの指標となるものです。例えば、火事が起こったら119番に電話しますし、泥棒に入られた時は110番に電話しますよね。誰も迷うことはないと思います。これは、明確な基準が定められているからですね。
私は相談ではなく明確な基準を決めるのがよいと考えています。それは、次のようなメリットがあるからです。
明確な基準があれば上長であろうが、あなたであろうが、誰が判断しても同じです。基準の前で立場は関係ありません。
誰が判断しても同じ結果になるわけですから、いちいち誰かに相談する必要はありません。忙しい上司を捕まえたり、関係者とMTGの時間を設定したり、説明する資料を作成する必要もありません。今、この場であなたが決めればいいのです。
相談と明確な基準の比較をするために、2つの組織を例として考えてみます。
1つ目の組織では最終的な判断は上長に相談する必要があります。意思決定をするのに上長とのアポイントメントや説明資料が必要です。意思決定を行うためには1日程度かかるかもしれません。
2つ目の組織は明確な基準があり、その基準をもとに問題に直面している当人が判断を行います。明確な基準があるので、その問題に直面している人がその場で決めることができます。
この2つの組織を比較した場合、生産性が高いのは明らかに基準が明確な組織です。このように相談と基準のどちらの戦略をとるかで、生産的な面においての差がみてとれます。
配信の手順としては次の通りです。
ゲームの動画と音声を録画するにはキャプチャボードが必要です。キャプチャボードには様々な種類があり、どれを使ったらいいのかよくわからなくなると思います(私がそうでした)。私のおすすめのキャプチャボードはI-O DATA HDMI キャプチャーボード GV-HDRECです。
このキャプチャボードは1万円程度と手頃な値段で操作方法も簡単です。最初の1台としておすすめできます。ただし、PCとの接続はできないので、リアルタイム配信には使えません。
私は32GBのUSBメモリを使っています。スマートフォンに接続できるタイプがおすすめです。録画した動画をスマートフォンで観たり、不要な動画を削除したりできます。
32GBで2時間程度の録画ができます(記録形式によって時間は変わります)。32GBだとこまめにデータを消す必要があるので、もう少し大きな容量がよいかもしれません。
画像の編集はiMovieを使っています。簡単な編集であればiMovieで十分です。YouTubeへのアップロード機能もついており、この機能を使ってYouTubeにアップロードしています。iMovieの操作方法についてはドキュメントをご覧ください。
アフレコに使うマイクはアップルの純正イヤホンのマイクを使ってます。
このような感じで、特に難しいことをせずに動画配信ができてしまいます。今後もスプラトゥーンの動画を配信していくので、ぜひチャンネル登録お願いします!
]]>時間のかかる処理などを並列で行い、その実行結果(終了ステータス)を取得したい。
Bashのサンプルコードです。スクリプトに解説を記入しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
gistにもコードをアップしています。
shellの学習は次の書籍を1冊やっておけば大丈夫です。
]]>では、最初は何がいいかというと、Sinatraがよいと思います。そういうわけで、Sinatraを使ったWebアプリケーションのサンプルを探してみたのですが、よいものが見つかりませんでした。ないなら作ってしまえというわけで作りました。
今回作成したのはシンプルなメモアプリケーションでフォームに入力した値をメモとして保存することができます。作成したメモの一覧表示、詳細表示、編集機能、削除機能を実装しています。基本的なCRUD操作を備えており、RESTについても学ぶことができるようになっています。
わかりやすいようにディレクトリをわけています。initialディレクトリは最初からフルスクラッチで作る場合のディレクトリです。step1はメモの作成とメモの表示機能を実装しています。step2はstep1の機能にメモの削除とメモの編集機能を追加しています。
実装にあたっては、できるだけRubyの標準ライブラリを使うようにしました。理由は長い年月において最も安定的に使えるのはRubyの標準ライブラリであることからです。サードパーティのライブラリは便利ですが、Rubyのバージョンアップによる互換性の問題などを含んでいます。将来的にも安定して動作させることを考慮すると標準ライブラリで実現できる機能であれば標準ライブラリを選択するのは良い選択肢だと思います。
また、データベース(正確にはRDBMS)はややこしいので使っていません。もう少し丁寧に説明すると、今回のアプリケーションはプログラミング初学者の学習に適しているアプリケーションをシンプルな実装(環境も含めて)で作るということを目的として作ったので、その点でRDBMSは適していません。では、どうやってメモを永続的に保持するのかというと、ファイルとして保持しています。この機能の実装には、Rubyの標準ライブラリであるpstoreを利用しました。pstoreとはオブジェクトをそのままファイルとして保存するライブラリです。メモアプリケーションの機能を実現するなら、これで十分なわけです。
Webアプリケーションはリクエストとパラメーター(必要であれば)をアプリケーションサーバーに送信し、ルーティング設定に従ってそのリクエストを処理します。そして、レスポンスを返します。この流れを理解することがはじめの1歩です。この流れが理解できていない状態でRailsを使うのは早すぎるように思いますし、データベースの用意やらマイグレーションやらは確実に最初の壁となってプログラミング初学者に立ちはだかるでしょう。
そのようなややこしいことは置いておいて、まずは小さな動くアプリケーションを作りましょう。Sinatraであればターミナルに数コマンドを打つだけでアプリケーションを起動できます。自分で全てのコードを書いても数時間程度で書くことができます。コードのほとんどは標準のRubyのライブラリを使用しているため、とてもシンプルです。
ここまではRailsについて散々けなしていますが、誤解のないように断っておくと、本格的なWebアプリケーションを作るのであればRailsがいいです。習得に数ヶ月はかかるでしょうが、多くの機能を少ないコードで実装できてしまうRailsの生産性の高さは、それだけの時間をかける価値があります。しかし、プログラミング初学者がいきなりRailsから入るのは難しいのではと思います。RubyでのWebアプリケーション開発は、まずはSinatraから入りそこからRailsに行くのがよいというのが私の考えです。
]]>「好きなことをひたすら追いかければよい」理由は、そのほうがうまくいく可能性が高いからです。
世の中には好きなことを極めることで、それが結果的に仕事になっている人がいます。例えばYoutuberのHIKAKINさんはその1人です。HIKAKINさんはヒューマンビートボックスを極め、それを自身の動画投稿に取り入れることにより一躍人気者になりました。
人気が出たのは誰もそのようなことをやっておらず、新鮮だったということがあると思います。ヒューマンビートボックスにハマり、動画投稿にハマり、自身の面白いを追求した結果、トップYoutuberになることができたのです。
このように世の中にないものには、計画を立ててそれを遂行するというやり方では到底到達できません。道はただ1つ。ハマってハマって追求するということです。
自身の面白いはとてつもなく大きな可能性を秘めています。今は何も可能性がないように思えるかもしれません。しかし、その面白いにハマり追求することで当初は見えなかった道が見えてくるはずです。
これは山登りに似ています。山の麓からは山しか見えません。山を登っていくうちにどんどん視界が開けて行きます。上から見ると、今まで見えなかった道が見えることでしょう。遠いと思っていた頂上も実際に歩いてみると、案外登頂できるものです。
実際にやってみると想像していたものと違うということもあることでしょう。その場合はさっとさとやめればいいのです。思い立ったらすぐやって、さっさと飽きて次に行く。飽きるということにネガティブなイメージを抱く人もいるでしょうが、飽きるということは経験し、そこからなにかしら学んだということです。どんどん飽きて、次の新しい経験を積めばよいのです。そのほうがたくさん学ぶことができます。飽きた数こそがあなたが成長した証です。
このように計画を立てずに面白そうなことはどんどんやる。飽きたらまた別の面白いことをやる。そうやって経験を積み、学んでいくことで、結果的にその経験が組み合わさって面白いことができるようになると思うのです。
]]>私自身は今年を特別な1年にしようなどとは微塵も考えていませんでした。また、何かを達成しようと詳細な計画をたてたりもしていません。しかし、結果的には今まで経験したことのないことをいくつか経験することができました。
ここで言いたいことは「計画していないけどうまくいった」ということです。
私はこのような経験を積むにつれて、計画を立てるのはあまり意味のないことなのではないか、と考えるようになりました。明確な計画を立て地道に進むというのは一見素晴らしいように思えます。しかし、実際は計画通りにいかないことがほとんどです。もし計画通りにいけば、みんな子供の頃に夢見たスポーツ選手や芸能人になっていることでしょう。
私たちは経験則で人生とは計画通りにいかないことを知っています。しかし、計画を立てようとしがちです。そして、年の暮れには「計画が達成できなかった。自分は無能な人間だ」と自分を蔑みます。そんなことに何の価値があるのでしょうか。ほとんどが失敗する計画をなぜ立てるのでしょうか。
いい加減、そのようなことはやめたほうがいいのではないかと思うわけです。私は「好きなことをひたすら追いかければよい」と思います。
理由についてはまた書いていきたいと思います。
]]>発表内容は0からはじまった開発チームが、どのようにチームとしてまとまっていき、アプリケーション開発を成功させることができたかという事例の紹介となります。
デブサミ福岡のような大きなイベントに登壇するのは今回が初めてなので、うまくできるか不安ではありますが、精一杯やりたいと思っています。もし、当日会場に来られる方がいれば是非、お声がけください。
]]>まずはWebRTCについての概要を把握しておくと、実装するときの理解が深まります。まずは、次の記事を読んでください。
同じタイトルですが、Qiitaのこの記事もわかりやすいです。
上記の記事を読んだら、早速コードを動かしてみましょう。コードを実際に動かしてみることで、着実にWebRTCの概念を理解していくことができます。
次の記事で簡単にPCのカメラの映像をブラウザに表示できることが体感してください。
次の記事でシグナリングの流れを掴みましょう。
本格的なビデオチャットを開発するのはなかなか大変です。その開発を楽にしてくれるサービスが世の中に存在します。私がおすすめするのはSkyWayというサービスです。このサービスを利用することでNAT越えなどの仕組みを自分で実装せずにすみます。日本語ドキュメントが整備されており、サービス自体も無料で試すことができます。
SkyWayを利用するにあたっては、次のスライドが参考になります。
余談ですが、WebRTCのライブラリであるPeerJSはメンテされてないので使わない方がよいです。
]]>フジツボスポーツクラブはデュアルスイーパーのような射程の長い武器は戦いづらいステージです。というのも、高低差が多く平らなスペースが少ないからです。塗り状況が悪い中で無理して中央のエリアに出て行ってもすぐに倒されてしまいます。
デュアルスイーパーの強ポジは自陣左側のスポンジです。スポンジを膨らませて、そこから中央高台にスプラッシュボムを投げます。このスプラッシュボムがかなり効果的です。というのも、エリアのルール上、中央高台には多くのイカが集まるので、スプラッシュボムが当たりやすいのです。また、自陣左側に敵が侵入してくることは少ないのでデスを抑えることができます。
数的優位がとれるまではスポンジの上からスプラッシュボムを投げる。数的優位が取れたら、中央に出て行ってエリアを押さえる。この動きができれば勝てます。
オススメのギアはサブ性能アップとサブインク効率アップです。サブ性能アップをつけると、スプラッシュボムの飛距離が伸びるため、より遠くの敵までボムが届くようになります。また、サブインク効率アップでより多くのボムを投げることができます。
空いたスペースには、インク回復アップとスペシャル増加量アップを積んでいます。これは、スプラッシュボムを投げる回数を増やすためとスペシャルのアメフラシの回数をあげるためです。アメフラシは相手の前線を強制的に下げさせることができるため、エリアの打開時にうってつけのスペシャルです。
]]>基本的に、予定があることがわかっている時は、何も仕事を終わらせられません。時計を見て「1時間後に会議があるから、この大事な仕事はまだやらないほうがいいな」と思ったり、1時間を20分くらいに感じるせいか、一番小さな仕事ですら無意識のうちに先延ばしにします。
30分後にMTGが予定されているだけで次の仕事をやる気がしなくなります。中途半端にやるくらいなら、MTGが終わってからやろうと思うからです。そして、MTGが終わると何だか疲れてしまい、少し休憩してからやろうと思います。さて、休憩もしたので仕事に取り掛かったのもつかの間、昼休みになります。このような感じで午前中に1つMTGが入っただけで、ほとんど生産的なことができずに午前中が終わってしまいます。たった30分のMTGが午前中をダメにしてしまいます。
このMTGのように、それ自身は些細な時間でも与える影響は大きいものです。その影響についても考える必要があります。
]]>もちろん、予選を突破してベスト16に入ったのはすごいことです。しかし、W杯で優勝するようなチームにとってベスト16に入るのは当たり前のことなのです。優勝候補のブラジルが決勝トーナメントの1回戦で負けたらブラジルの世論はなんと言うでしょうか。おそらく、酷いバッシングをするはずです。
この空気がブラジル代表の選手たちの潜在意識に強く影響をしているわけです。ブラジルの選手たちはベスト16で勝つのは当たり前。絶対に負けられないと100%信じているはずです。
対して、日本代表の選手たちはベスト16になったことで少なからず何処かに満足感があると思います。これは選手たちのせいではなく、日本の世論が作り出している雰囲気のせいです。
開催国のほとんどが予選を突破して決勝トーナメントに進出するのも同じ理由です。自国開催のチームは絶対に予選を突破しないといけないと潜在意識に強く刷り込まれているわけです。
日本の空気感こそがサッカー日本代表の最大の壁だと思います。
]]>朝から会社の判断を待ってどうするかが決まるなんてわずらわしくないですか。出社を判断する方も大変でしょう。会社が判断するのではなくて個々人で判断すればいいのです。会社で働いたほうが都合がいい人は会社で働けばいいですし、会社以外で働いたほうが都合がいい人はリモートワークをすればいいだけです。
]]>1 2 3 4 |
|
Builderを実装したUserクラスのサンプルコードです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Setterを使うと次のようになります(実装は省略)。
1 2 3 |
|
Setterの問題点として、インスタンスの状態を変更してしまうことがあります。イミュータブルな実装にする場合、原則としてコンストラクタで値は設定するべきでSetterで変更するべきではありません。
では、Setterではなくコンストラクタで設定するようにしましょう。引数が少ないうちは問題がないのですが、次の例のように引数の数が増えてしまうとコードが煩雑になってしまいます。
1 2 3 |
|
そこで、Builderを使うメリットが出てきます。Builderを使えば柔軟にパラメーターの設定が行えるようになります。
1 2 3 4 5 |
|
SetterもBuilderもやりたいことはオブジェクトにパラメーターをセットすることです。Setterを使うとオブジェクトの状態を変更してしまうことになります。イミュータブルな実装かつ柔軟にパラメーターを設定したい場合はBuilderを使いましょう。
]]>Spring Bootも2系からはlombokは使っていませんね。
lombokは便利ですが、別に無くてもなんとかなるライブラリなので、あえてこれから使う選択をする必要はないと思います。
]]>リモートワークの利点として会議に出なくていいことがあります。会社にいると何かと会議に招集されて時間や集中力が奪われてしまいますが、リモートワークであればその心配はありません。本当に出る必要がある会議であればリモートで参加すればいいですし、多くの場合は対面で話さずともドキュメントベースのコミュニケーションで事足ります。
ほかにも通勤時間が不要になることで1日に余裕ができるメリットがあります。私は往復で通勤時間に2時間が必要です。リモートワークにすればこの2時間が自由に使えるようになります。通勤時間がない分、早めに仕事を切り上げてその後の時間は子供と遊んだりできます。
リモートワークだと集中できない、生産性が下がるという意見がありますが、実際にやってみるとそんなデメリットはありませんでした。オフィスより家の方が集中できます。なぜなら、集中するには静かな場所が必要だからです。テレビがついているような騒がしい場所で集中することは難しいのです。オフィスはテレビがついている部屋と大して変わらないと思います。
リモートワーク導入で生産性が下がるのではないかという意見もありますが、そんなことはありません。通勤時間がなくなるうえ、集中できる環境であれば生産性が上がるのは当然でしょう。コミュニケーションが必要な時はSlackなどのツールを利用すればよいです。ただし、100%リモートワークとなるとコミュニケーションの問題が出てくるであろうというのはわかります。ですので、オフィスワークとリモートワークのハイブリットがバランスがよいのではないでしょうか。
頑張って残業するよりリモートワークを取り入れましょう。そのほうが生産性があがり社員の満足度もあがりますよ。
]]>@Makingさんの記事「紙媒体の技術書を書きたくないです…」に書かれているように技術書を書くには膨大な時間が必要です。それを全て書き終えて出版するには相当の時間がかかります。ITの技術はどんどん進歩しているので、出版される頃には古くなってしまう場合もあります。紙媒体だと内容が間違っていても修正できません。また、出版の期日に間に合わせるために、著者に非常に負担がかかります。今の出版のやり方はデメリットが多すぎるんですよね。
だいたい技術書の内容って全ては必要ない場合がほとんどです。一部だけ読みたいのに全てを購入するのは無駄なのです。これからはnoteなどのサービスを使って有料で出版されるケースが増えてくると思います。そうすれば、自分のペースで書けるし取り分も増えます。読むほうも必要なところだけ買えばいいので無駄がありませんね。
]]>