末期がんなのに元気 昔、「エイリアン」というSFホラー映画があったが、これはがん細胞からヒントを得たと言われている。 実際、宿主の人間を動けなくしておいて、身体を食べ尽くすところがエイリアンにそっくりだが、決定的に違う点がある。それは、エイリアンはみんな同じ顔をしているが、がん細胞は、場所や人によって顔つきがまったく違うことである。 原因は、正常細胞の遺伝子がランダムに損傷を受けてがん細胞になり、長い年月の間にさらに変異を繰り返してきたからだ。分子標的薬が効かないのも、がん細胞はカオスのように変異だらけだからである。 P-THPは、理論的にどんながんもやっつけられそうだが、そうならないのは、がんはカオス的世界だからである。 たとえば、山藤ひろ子さんである。彼女は64歳のときに直腸がんが見つかった。 外科手術で取れたが、4年後に肺に転移したため抗がん剤治療を始めた。それ以来、1年半にわたって

ソフトウェアのセキュリティは複雑な問題だが，それぞれのサービスがセキュリティを扱わなくてはならないマイクロサービスを採用することで，さらに複雑なものになる – 先日ロンドンで開催されたMicroservices ConferenceでDavid Borsos氏は，マイクロサービスベースのシステムにおける４つのエンドユーザ認証方法を評価した自身の講演の中で，このように説明した。 従来のモノリシックなアーキテクチャでは，ひとつのサーバがすべてのユーザ情報を保持することで，認証されたユーザの検証とHTTPセッションの生成を行なうことが可能だ。マイクロサービスアーキテクチャでは，ユーザはサービスの集合体と対話するため，それぞれのサービスがユーザが誰であるかを知る，潜在的な必要性がある。単純な解決方法は，モノリシックなシステムと同じパターンをマイクロサービスシステムにも適用することだが，すべてのサー

はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ （Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります） https://github.com/google/styleguide Shellスタイルガイド （今回はこちら） http://google.github.io/styleguide/shell.xml 本当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 （見たところcpplintはc++だけだと思ってます） commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ

最近言われているようにプログラミングは必修化の方向にある。 文科省でも、まじめにその在り方を議論してきているくらいだ。 小学校段階におけるプログラミング教育の在り方について（議論の取りまとめ）：文部科学省 僕はもともとキャリアの最初でプログラミング（大規模システム開発プロジェクトでコーディングしたり仕様書を書いたりすること）に携わっていたし、振り返ってみれば小学六年の頃（1980年頃だ）からNECのPC-8001でBASICのプログラミングをしていたので、いわゆるプログラミングスキルはある方だと思う。 でも、自分はたまたま興味があってそういうスキルを身につけたけれど、自分の子どもに教えるとなるとなかなか難しいなぁ、と考えていた。 というのも、すでに完成されたアプリが多すぎるからだ。 僕が初めてＰＣに触れた1980年台といえば、もちろんwindowsなんかなくて、真っ黒な画面のコマンドプロン

定期的に自分の思考を言語に変えていく作業は必要だなぁと感じて、年末に時間が空いたのでこの１年半ぐらい考えていたことをまとめてみることにしました。 以前ブログで、世の中は連立方程式のようなもので、３つ（お金・感情・テクノロジー）の異なるメカニズムが併存し相互に影響を及ぼしており、それらが未来の方向性も決めている、という話を書きました。３つの要素がそれぞれ違うベクトルを指して進んでいます。それらの先端を結んだ三角形の中間が「現在」であり、その軌道が「未来」の方向性であると。３つのベクトルではお金が最も強く、次に人間の感情、最後にテクノロジーの順番としていました。 ただ、この時はまだモヤモヤしていて、もう少し掘り下げればより普遍性のある構造が隠れているように感じていて、この１年半は日々のビジネスで試行錯誤しながら、ずっとこのテーマを考えていました。書籍やブログではテクノロジー系の話ばかりしていて

Build a serverless URL shortener with AWS Lambda and API Gateway services I’ve had my eye on Amazon’s Lambda and API Gateway services for a few months. Running a web application without the costs or headaches of maintaining servers is attractive. Of course, no platform is without tradeoffs. So to get myself familiar with the finer points of serverless apps I decided to launch a simple project: a U

大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ

趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability（信頼性） Availability（可用性） Serviceability（保守性） Integrity（保全性） Security（機密性） 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので

さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分

みなさん、こんにちは。Retty CTO の樽石です。 この記事は Retty Advent Calendar 25日目です。メリークリスマス。 昨日は @ttakeoka の『MFIにむけてRettyの取り組み』でした。 今年も残りわずかになりました。いかがお過ごしですか？ Retty はこの １ 年でエンジニアがほぼ倍増しました。それによって、情報発信者が増え、Advent Calendar に参加出来るようになりました。みんな楽しそうにしていて、うれしいです。 Retty Inc. Advent Calendar 2016 - Qiita さて、今年最後の Retty Advent Calendar 記事を書くということで、はじめは １年のまとめ的内容にしようかと思いましたが、それでは平凡で面白くありません。そこで、ネタになりそうなマニアックな技術的記事で締めくくりたいと思います。

「エンジニアとしてのものづくりの楽しみ方とモバイルエンジニアとしての開発の面白さ」を論じる。スキル向上に悩めるモバイルエンジニアへの参考として価値を期待し、モバイルアプリ開発の奥深さに考えを巡らせることで強い動機を持ち、次の挑戦が見えてくる。

この記事は Go (その2) Advent Calendar 2016 の24日目の記事です。 この記事では 去年からずっと趣味で Go を使ってリアルタイム通信ゲームサーバー作っていて、それなりに動くものができたので、それを紹介したいと思います。 リポジトリはこちらです。 https://github.com/shiwano/submarine 一部 Unity の有償アセットを除いている以外、クライアントもサーバーもすべてのコードをここで公開しているので、もし気になる実装があったら見てみてください。 以下、簡単なディレクトリの説明です。 . ├── art # デザインまわりのファイル置き場 ├── client # Unity クライアント (C#) ├── contract # 通信定義ファイル置き場 (TypeScript) ├── server │   ├── api # Ra

この記事はCyberAgent Developers Advent Calendar 2016 24日目の記事です。23日目はdekatotoroさんの「Apple TV – tvOS入門」でした。 こんにちは、AbemaTVサーバサイドエンジニアのギアです。 去年は新卒のiOSエンジニアとして、「ReactiveCocoaとMVVMモデル」という記事を書きましたが、今年はサーバサイドに関することを書きます。 はじめに この前にAbemaTVはモニタリング・アラートのため、主にStackdriver, Bugsnag, StatusCakeというサービスを使っています。しかし、Stackdriverはデフォルトである程度のGCP (Google Cloud Platform) 上のリソースに対するメトリクスしかありません。各マイクサービス間の通信やサービスのカスタマイズメトリクスなどのアプ

サーバーサイド開発担当のエンジニアが「設計と実装を進めようとしている」という背景で話を進めます。 PlantUMLは強い 「認識合わせ」という名目でホワイトボードに図を書いて会話することがよくあります。共通言語で会話してあいまいなところを少なくしたら、マネージャーも安心感がありますし、プログラマも自分がやるべきことに集中できますね。 …3日経ちました。あのとき描かれていたホワイトボードの図のとおりに、実装することになりました。認識の齟齬をなくしてくれた貴重な図です。写真に撮りました。どこに保存してたっけ。やっぱり変更したくなったらどうしましょう。またホワイトボードに書き起こす？DRYじゃないですねえ。 そこで、UML図 が登場します。表現したい図を電子データで作成、保存できて、あとで見るときも役に立ちますね。が、しかし、UML図はそれはそれでやや手間がかかるところもあります。作図を助けてく

シェルスクリプトは長くなると処理の境界が不鮮明になりがち。 コメントで処理の境界を表現する工夫はよく見かけるが、もっと良い方法はないか考えてみた。 :コマンド、&&演算子、複合コマンド()や{}を組み合わせて書くと、処理の境界線がはっきりする。

QCon London 2016において、Peter Bourgon氏は「Successful Go Program Design, 6 Years On」というプレゼンを行い、Goでプログラミングするときに使うべきパターンと避けるべきパターンについて説明した。 GOPATH: 環境変数PATHにGOPATH/binを加え、関係バイナリを簡単にアクセスできるようにする。Bourgon氏は一つのグローバルなGOPATHを使うことを推奨する。たいていの場合、これでうまくいく。自分のコードと外部依存のコードを明確に分離したい人は、2つのGOPATHを作るのが好みだろう。gbを使って、環境変数をセットせずにプロジェクトごとに構築するという選択肢もある。 リポジトリ構成: リポジトリの構成はプロジェクトに依存する。プライベートなプロジェクトで決して公開しないなら、好きな構成で構わない。オープンソース