シェルスクリプトで別プロセスの終了ステータスを取得するTipを紹介します。
ユースケース
時間のかかる処理などを並列で行い、その実行結果(終了ステータス)を取得したい。
サンプルコード
Bashのサンプルコードです。スクリプトに解説を記入しています。
1 |
|
gistにもコードをアップしています。
shellの学習は次の書籍を1冊やっておけば大丈夫です。
シェルスクリプトで別プロセスの終了ステータスを取得するTipを紹介します。
時間のかかる処理などを並列で行い、その実行結果(終了ステータス)を取得したい。
Bashのサンプルコードです。スクリプトに解説を記入しています。
1 |
|
gistにもコードをアップしています。
shellの学習は次の書籍を1冊やっておけば大丈夫です。
私はソフトウェアエンジニアなのですが、プログラミング講師としても生徒さんにRubyを教えています。RubyでWebアプリケーションを作る場合、まず候補になるフレームワークはRuby on Railsですが、Railsは初学者には難しいと思います。プログラミング初学者にRailsを教えるということは、車の教習所でいきなりスポーツカーを運転させるようなものです。入門者には入門者に適した車があるのと同様にプログラミングにもそのようなものがあります。
では、最初は何がいいかというと、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に行くのがよいというのが私の考えです。
2018年9月7日にアクロス福岡で開催される Developers Summit 2018 FUKUOKA(デブサミ福岡)に登壇します。
明日はどのような話しから入ろうかがまだ決まっていなくて、どうしようかと考えています。
発表内容は0からはじまった開発チームが、どのようにチームとしてまとまっていき、アプリケーション開発を成功させることができたかという事例の紹介となります。
デブサミ福岡のような大きなイベントに登壇するのは今回が初めてなので、うまくできるか不安ではありますが、精一杯やりたいと思っています。もし、当日会場に来られる方がいれば是非、お声がけください。
ビデオチャットを最短で作りたいと考えている人への備忘録です。次の手順に沿って開発すると4時間程度でビデオチャットを開発できます。
まずはWebRTCについての概要を把握しておくと、実装するときの理解が深まります。まずは、次の記事を読んでください。
同じタイトルですが、Qiitaのこの記事もわかりやすいです。
上記の記事を読んだら、早速コードを動かしてみましょう。コードを実際に動かしてみることで、着実にWebRTCの概念を理解していくことができます。
次の記事で簡単にPCのカメラの映像をブラウザに表示できることが体感してください。
次の記事でシグナリングの流れを掴みましょう。
本格的なビデオチャットを開発するのはなかなか大変です。その開発を楽にしてくれるサービスが世の中に存在します。私がおすすめするのはSkyWayというサービスです。このサービスを利用することでNAT越えなどの仕組みを自分で実装せずにすみます。日本語ドキュメントが整備されており、サービス自体も無料で試すことができます。
SkyWayを利用するにあたっては、次のスライドが参考になります。
余談ですが、WebRTCのライブラリであるPeerJSはメンテされてないので使わない方がよいです。
スプラトゥーン2のデュアルスイーパーカスタムのフジツボスポーツクラブの立ち回り(ガチエリア編)を解説します。
フジツボスポーツクラブはデュアルスイーパーのような射程の長い武器は戦いづらいステージです。というのも、高低差が多く平らなスペースが少ないからです。塗り状況が悪い中で無理して中央のエリアに出て行ってもすぐに倒されてしまいます。
デュアルスイーパーの強ポジは自陣左側のスポンジです。スポンジを膨らませて、そこから中央高台にスプラッシュボムを投げます。このスプラッシュボムがかなり効果的です。というのも、エリアのルール上、中央高台には多くのイカが集まるので、スプラッシュボムが当たりやすいのです。また、自陣左側に敵が侵入してくることは少ないのでデスを抑えることができます。
数的優位がとれるまではスポンジの上からスプラッシュボムを投げる。数的優位が取れたら、中央に出て行ってエリアを押さえる。この動きができれば勝てます。
オススメのギアはサブ性能アップとサブインク効率アップです。サブ性能アップをつけると、スプラッシュボムの飛距離が伸びるため、より遠くの敵までボムが届くようになります。また、サブインク効率アップでより多くのボムを投げることができます。
空いたスペースには、インク回復アップとスペシャル増加量アップを積んでいます。これは、スプラッシュボムを投げる回数を増やすためとスペシャルのアメフラシの回数をあげるためです。アメフラシは相手の前線を強制的に下げさせることができるため、エリアの打開時にうってつけのスペシャルです。