最強のヒストリ補完を求めて シェルヒストリに不満を持っていたので自作しました。今の自分にとっては必要な機能を盛り込んでいて便利に使えていますが、誰かにとっては、もしくは数カ月後の自分にとってはぜんぜん最強じゃないかもしれないです。 以前このようなエントリを書きました。 www.tellme.tokyo このころから (いやもっと前から) シェルのヒストリ補完に不満を持っていました。 単純にデフォルトの C-r だと目的のものを探しづらい 例えばコマンド名の一部だけだとノイズが多すぎる けどディレクトリは覚えているからそれでもフィルタしたい、とか 他にも色々あって (その理由について先のエントリを見てもらうとして) zsh-history というツールを書きました。 GitHub - b4b4r07/zsh-history: A plugin for zsh history extended

新規事業の検討が増えている 新規事業の検討をお手伝いすることが、ここ数年で飛躍的に増えてきました。 ベンチャー企業が増加していてそのお手伝いを、というよりは いわゆるレガシー企業が「新たに何かやらなくては！」と検討を開始されるケースです。 規模は大企業から零細まで、場所も東京から地方の郡部までと本当に様々です。 背景にあるのは、既存事業（コア事業）の伸び悩みであったり、 既存事業そのものは現状順調であるが10年後の外部環境を見据えると不安…という場合のいずれかに分類されます。 （本当は、伸び悩む前にご相談いただきたいこともあるのですが、まあそこはご縁ですから・・・） 「新規事業がざっとわかる本」を求める若手の方 で、プロジェクトとなると経営企画部かそれに準ずる部署の部長クラスと若手（入社3～5年目くらい）、というチームが配置されます。 そして若手の方が事務局とか社内調整をご担当されるわけで

PPLサマースクール2016「商用Java処理系の研究開発」のパート2です． http://ppl.jssst.or.jp/index.php?ss2016 Java言語処理系の実装について詳説する．まずJava仮想マシンの概要について述べ，その主要な構成要素として，クラス管理とインタープリタ，ヒープ管理とガベージコレクション，スレッド管理と同期機構，JITコンパイラとの連携，などについて説明する．性能改善のために行った各種手法についても触れる． 他のパート 1 Javaの登場と発展 http://www.slideshare.net/Tamiya_Onodera/java-66081108 2 Java仮想マシンの実装技術 http://www.slideshare.net/KiyokuniKawachiya/java-66003903 3 Java Just-In-Timeコンパイラの

こんにちは、皆さん。 Python言語の実装に深く踏み込む前に、Pythonの主要な概念を知っておく必要があります。それは非常にシンプルで、 全てがオブジェクトだ ということです。このことは、Pythonの内部構造を学習する際の最初のステップであり、この旅の入り口でもあります。 今回の主なテーマは、Pythonのオブジェクトが実装レベルでどのように扱われているかを理解することです。私たちは、 Python 2.7.8 のCPythonの実装について話をしていきます。 Pythonのソースをダウンロードし、解凍することを想定しているので、ソースコードへの参照は全て、ルートフォルダからの相対的な参照になります。 PyObjectとPyVarObject Pythonでは全てがオブジェクトです。Pythonで使われている以下のものは文字通り、全て C の PyObject です。 関数 スライス

This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

近年、Kindle Unlimited の日本上陸により、我々の進捗はますますダメになっている。理想状態において、無限に漫画を読み続けることができれば、人は進捗を完全に停止させることができる。しかしこの仮定は、如何にして読みたい作品を発見するかという問題に我々を導く。 Kindle Unlimitedで作品を探す方法として、masawadaの日記 では「刊行数が少ない出版社順にタブを開く」「星4以上の書籍に限定する」「あとはがんばって全部みる」という手法が紹介されている。id:masawada はこの課題について新たな試みを行ったが、多くの人間はがんばる気概を持ち合わせていない。 先月から開発を始めた amakan.net では、それぞれの作品ごとに、漫画やラノベのシリーズ判定、Kindle Unlimited対応判定、読みたい本・読んだ本の管理を行っている。そこで、このデータを利用して「

C++の設計者ストラウストラップによるプログラミング入門書の最新版日本語訳が、9月に @asciidwango から出版されます。 https://t.co/ssT9ubfXtT — アスキードワンゴ編集部 (@asciidwango) August 5, 2016 アスキードワンゴ編集部からBjarne StroustrupのProgramming -- Principles and Practice Using C++という本の第二版の邦訳が出版される。初版は翔泳社が出していたが、C++14に対応した改訂版の第二版の版権が空いていたので、アスキードワンゴから出すための作業をしていた。私は邦訳の査読をした。 今年になってから半年は、ずっとこの本の査読をしていた。このためにC++標準化委員会の最新の文書を把握する作業が数ヶ月ほど滞った。そして、この仕事は、私がドワンゴに入社して以来、最悪の

CSSプロパティの1つである display は、CSSレイアウトに用いるプロパティの中でも極めて重要なものです。よく使われているのは、 block や inline 、 none あたりでしょう。 table や inline-block も、今ではかなり一般的になってきたと言えます。一方、 flex は新たに登場したものです。きっとユーザに気に入られるでしょう。これはレイアウト用に特別に作られたdisplayプロパティです。さらには、この先、 grid がまもなく私たちの秘密兵器となるでしょう（現在、盛んに取り組まれています）。これもまた、レイアウトに特化したプロパティです。 本記事は、当初予定していたよりもずっと長くなりました。ご希望に応じて、自由にサブセクションに飛んでお読みいただければと思います。もし、お時間を割いて全体を読んでいただけるのでしたら、大変嬉しく思います???? 目

私がリスペクトするエンジニアの一人であり、ITエンジニア界隈の三大野球バカの一人*1であるござ先輩が本を出版されました. gothedistance.hatenadiary.jp 大変ありがたい事に、献本を頂いたので久々に書評など書いてみようかなと思います. [書評]「独習Python入門」 どんな本なのか 私の感想も含めて. Pythonを元にしたプログラミングの入門本 一人で学ぶ(独習)するときにハマりがちなポイントや、ステップアップするときに必ず覚えたほうがいい事を言葉の緩急を駆使していい感じに解説している！ 本を一冊やり切った(写経)した後も自宅の本棚に置いておきたい&必要に応じて再び読みたくなる本 私は読者層に当てはまらないのですが（汗）、初心者の気持ちになって思い出しながら読んで、 「ああ、最初にプログラミングを学ぶ本がこの本みたいなスタンスだと凄くいいな」 と素直に思いました

昨日僕の Twitter タイムラインで q というツールが話題に上がっていました。 GitHub - harelba/q: q - Run SQL directly on CSV or TSV files Text as Data q is a command line tool that allows direct execution of SQL-like q... https://github.com/harelba/q 標準入力を SQL で抽出できるという物です。ただ個人的には「こういうの python じゃなくて Go でビルドされてると助かるよなー」と思ったので q と同じ様な動作になるツールを作ってみました。 GitHub - mattn/qq Select stdin with query https://github.com/mattn/qq 例えば msys2 のシ

Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可

言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。

以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの

今年、いわゆるデータサイエンティスト的なスキルの後輩が入ってきて、私がメンターの役割を任されました（正確にはメンターになるはずのメンバーが抜けてしまい、早いタイミングで私が引き継ぎました）。 彼は、今時珍しく(?)、数学的な能力と、その手法を実世界に結びつけるセンスを兼ね備えて持っています。 ただし、プログラミングやエンジニアとしてのスキルは、入社時にはあまり持っていませんでした。 せっかくメンターになったので、ナントカっていう分析手法の話を「わかんねえなあ」って思いながら聞いてたり、「こういうこと勉強したらいいんじゃない？」とか唆したり、自分や同期がつらいと思っていたところを取り除いてたりしてました。その甲斐あったのかは分かりませんが、割と楽しんで仕事しているようだし、エンジニアとしてのスキルも順調につけていっています。 そこで、メンターの立場で心がけたことや、スムーズに業務できている要

昔から気をつけてることなのだけど、ある程度、ブログ、とくに技術テーマ以外の記事を書く頻度はコントロールしよう、と思っていた。具体的には、1ヶ月の間に2, 3回ホッテントリなどに入ることは問題ないが、2, 3ヶ月連続で耳目を引き続けるのは、避けた方がいいのではないか。とくに落ち着いて暮らしたいなら。 中長期的にあまりに注目を引き過ぎると、勝手に記事間の文脈を悪意を持って補完されたり、固定のウォッチ対象にされてしまったりすることがある。粘着なアンチは聞く耳を持たないので無視するに限るが、人間何に反感を持つかわからないもので、自分がコントロール出来ない要素をたくさん抱えると、書くことそのものが億劫になっていく。日常生活にも影響が出る。少なくとも僕は、自分が書いたものが自分のコントロール下から外れていないか、怖くなってエゴサーチばっかりしてしまう。 「悪意を持ったコメント」に対抗する方法は難しく、

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

iPhone アプリを作ってきて 私が iPhone アプリ開発を始めてからおよそ4年が経過しました。 その間に得た知見の一部を紹介致します。 この記事の対象読者は以下の方を想定しています。 これから iOS プログラミングを始めたい方 今まで本格的に iPhone アプリを作ってはいないけれども、興味がある方 開発の事はよくわからないけれども、アプリのプロモーションなどを担当している方 これから iPhone アプリ開発に携わるのであれば覚えておきたいこと 言語について モダンな書き方をする → Objective-C でもジェネリクスなどを積極的に使う 冗長な書き方をしない → [[Class alloc] init] は [Class new] と同等 Swift は GitHub の Release や Issue などを追う → オープンソースの活用 豊富なOSSを活用する →

(追記1：2016/7/11　7/7以降のブログ記事などを追加) (追記2：2016/11/24 延期発表の記事を追加) こんばんは。SE兼PM見習いです。 例のみずほ銀行の次期システム開発が話題になってますね。 blog.livedoor.jp blog.livedoor.jp 毎年この時期に、みずほ案件がグダグダだよね、という情報が出てくるのはもう恒例行事となってますが、開発工程終盤を迎えていよいよヤバイ状況が隠しきれなくなっているようです。 趣味が悪いと言われますが、デスマウォッチャーでして、特にこのみずほ銀行案件をウキウキとウォッチングしているのですが、ここでブックマークしている過去の情報を時系列に振り返ってまとめてみたいなと思います。 2002年〜合併時のシステム障害〜 次期システム案件の話に入る前に、みずほ銀行合併時の大規模システム障害に触れておく必要があります。 https: