構造化テキストデータを操作するためのコマンドラインツールリスト | POSTD
テキストベースのファイル形式と、それぞれを（主にLinux上で）操作するためのコマンドラインツールのリストを掲載しています。 目次 DSV XML,HTML JSON YAML,TOML INI 設定ファイル おまけ：単一ファイルデータベース用コマンドラインインタフェース（CLI） ライセンス 情報開示 DSV CSV や TSV などを含む DSV（Delimiter-separated values、区切り文字で区切られた値） です。 Awk AwkはPOSIXで標準化されているコマンドラインツールで、DSVデータ処理用プログラミング言語です。Awkに関するリンクは以下のとおりです。 Awk.info — Awkに関する情報が豊富です。 AWK Vs NAWK Vs GAWK —プラットフォーム別実装の比較です。 すでにプログラミング言語を使用してプログラミングをしている場合は、naw
プログラミングの名言をもう少し | POSTD
前回投稿した「 The Wisdom of Programming （プログラミングに関する名言の知恵）」で、表面上は良さそうでも、ソフトウェアの開発において誤った考えを助長する結果になってしまう名言に注意を促しました。また、以前には「 favorite programming quotes 」（お気に入りのプログラミングの名言）というのも投稿していますが、もう少し名言を追加しておきたいと思います。 コーディング作業 「プログラムを詳細にわたって明確に記述する作業とプログラミングの作業は、全く同一のものである」―Kevlin Henney 「プログラム構築の本質のほとんどは、実際には仕様書のデバッグだ」―Fred Brooks 「よくある誤った考えは、プログラムの作成者は不可解なコードを書いてもコメント行で自分の考えを明確に表現できるだろうと思い込むことである」―Kevlin Henney
ソフトウェアのスケーラビリティについてスターバックスが教えてくれること | POSTD
2004年に Gregor Hohphe が「 スターバックスでは2相コミットを使わない（Starbucks Does Not Use Two-Phase Commit） 」という優れた投稿を発表しました。それを読んでいたら、学生時代にスターバックスでアルバイトをした頃がいきなり関わってきました。何年もの間に次第に分かってきたのは、プログラマでさえ有名なコーヒーショップのチェーンから学べることが思った以上にあるということです。 多くの人はスケーラビリティのあるソフトウェアを作ろうしますが、最初に考えていたよりも非常に難しいことがあります。個々のタスクをこなしているうちに「あらゆるものの重要性は等しく、同じリソースを必要とし、決まった順序で同期的に進行する」と考えてしまう罠に陥ってしまうのです。 実際には、少なくともスケーラビリティのあるシステムでは、当てはまりません。もちろんスターバックス
JavaScriptユーザのための関数型プログラミング(前編) | POSTD
私が関数型プログラミングについて度々耳にするようになったのは、数カ月前からです。でも当時は、それが何なのか見当もつかず、単なるバズワードだと思っていました。皆さんの中にも、そのような方は多いでしょう。それ以来、私は関数型プログラミングについて深く学び、この言葉を日々聞いてはいるものの内容を理解していない初心者の方のために、分かりやすく説明しようと思い立ちました。 関数型プログラミング言語の話になると、「 Haskell と Lisp は どちらが優れているのか 」という 議論 が 白熱する 傾向にあります。HaskellとLispはどちらも関数型言語ですが、実際には大きな違いがあって、それぞれに長所と短所があります。その具体的な内容については、この記事を読み終える頃には深く理解していただけると思います。この2つの言語には、それぞれから派生した言語があります。その中で恐らく皆さんが耳にしたこ
画像処理入門講座 : OpenCVとPythonで始める画像処理 | POSTD
この記事を書くに至ったきっかけ Recruse Centerでは、私は、画像処理の勉強に時間を費やしていました。独学をし始めた頃は、何をするものなのか全く理解しておらず、ただ、文字や輪郭、模様などを識別するのに役立ち、これらで面白いことができる、ということくらいの知識しかありませんでした。 私の情報源は、主にWikipediaや書籍、公開されている大学の講義ノートです。これらの資料に慣れ親しんでくるにつれ、画像処理の世界における基礎を伝えられる「入門向け画像処理」を望むようになりました。 これが、この記事を書こうと思ったきっかけです。 前提条件 この記事は、Pythonが扱えるということを前提に書いています。その他の事前知識は必要ありませんが、NumPyや行列計算に慣れていると理解しやすいでしょう。 初めに 使用するのは、Python版OpenCV、Python 2.7 ^(1) 、iPy
APIデザインにおける七つの大厄介 | POSTD
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か
Angular 2で作った最初のアプリの事後分析 : 使ってわかったAngular 2の長所と短所 | POSTD
最近、Angular 2を使ってWebアプリ作成の手伝いをする機会がありました。このフレームワークの複雑さに戸惑いもありましたが、Angular 2は間違いなくすばらしいものです。この事後分析では私がAngular 2のフレームワークを使った時に感じたいい面と悪い面の両方を掘り下げていくことにします。 Angular 2 Angularは携帯電話やデスクトップのWebアプリケーションを作成するための開発プラットホーム。 https://angular.io/ Angular 2＋リアクティブプログラミング＝❤ 私はすでに、Angular 1アプリケーション ではRxJSをかなり使っていました。特に、サービス間のメッセージ・バスを行うアプリを作成する時です。Angular 2はObservableを非常によくサポートしているので、アプリ全体にリアクティブプログラミングを取り入れることができ、
Go言語の並行性を映像化する | POSTD
Goというプログラミング言語の強みの１つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす
2016年、C言語はどう書くべきか (後編) | POSTD
(前編はこちら： 2016年、C言語はどう書くべきか (前編) ) (編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int
2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
Railsの基本理念 : Railsの生みの親が掲げる8つの原則 | POSTD
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
ES6 チートシート | POSTD
日々の仕事の中で役に立つES2015（ES6）のティップス、コツ、ベストプラクティス、プログラムの見本をご紹介します。コントリビューション歓迎です！ 目次 var vs. let / const IIFEからブロックベースへ アロー関数 文字列 デストラクチャリング モジュール パラメータ クラス シンボル マップ WeakMaps Promises ジェネレータ Async/Await var vs. let / const var の他に、値を格納する let と const という識別子が新たに追加されました。 var とは異なって、 let と const はクロージャのスコープ内で最初に記述されることはありません。 var の使用例です。 var snack = 'Meow Mix'; function getFood(food) { if (food) { var snack
WebSocketには注意が必要 | POSTD
近い将来WebSocketがRailsで使用できるようになると聞くと、デベロッパはみんな舞い上がって興奮します。 しかし、 あなたのユーザは、あなたがWebSocketを使用しているかどうかなんて気にしません 。 ユーザは、”快適なリアルタイムWebアプリ”を求めている。 デベロッパは、”快適でビルドが簡単なリアルタイムWebアプリ”を求めている。 オペレーションは、”デプロイ、スケール、管理が簡単なリアルタイムWebアプリ”を求めている。 上記全ての要望をWebSocketがかなえてくれるのなら素晴らしいことですが、この実装の詳細は高いコストがかかります。 超高性能で全二重なクライアントとサーバ間の通信は、本当に私たちに必要なのか？ WebSocketは、クライアントに情報を配信するための簡単なAPIと、クライアントからWebサーバへ情報を送信するための簡単なAPIを提供します。 サーバ
AWSで避けるべき5つの間違い | POSTD
今年からAWS（Amazon Web Services）クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈：（左から）DNS、CDN、静
分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS! ：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー
100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す | POSTD
100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す MySQLはNoSQLよりも優れています。Key-ValueストアといったNoSQLのユースケースを考えてみると、パフォーマンスや使いやすさ、安定性の点でMySQLの方が合理的です。MySQLには、オペレーションや障害に関することからレプリケーションや異なる使用パターンまでと、多くのオンラインマテリアルが用意されおり、堅実なエンジンです。こういった理由から、比較するまでもなく、MySQLは最近のNoSQLエンジンよりも優れていると言えます。 ここ最近では、NoSQLエンジンが主流になってきています。多くの開発者が、MongoDBやCassandra、Redis、HadoopといったNoSQLエンジンをアプリケーション構築の第一候補としており、それらが全て昔からのSQLエンジンを上回
TCPを（少しは）理解しておくべきその理由 | POSTD
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
