1. Attacking against 5 million SSH public keys 偶然にも500万個の SSH公開鍵を 手に入れた俺たちは hnw 江戸前セキュリティ勉強会 (2015/1/24)発表資料
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。(色んな使い方があります) 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった!まさにこれだ!と思いました。 よし、コードレビューをしよう! 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい! search_word_arrays = param
何でもホイホイ作ってみれば良いと思う 物作りを生業とする以上は何でもかんでも呼吸のように生み出していきたい。 今回はホイホイ会社を作ってみた。 プログラムの設計をするように組織の設計をしていきたい。 パケットの送信をするように役所手続きをしていきたい。 オープンソースにコミットするように社内ノウハウを放出していきたい。 定款は Markdown で作った。 2015年度の目標は事務所を持つことだ。志高い方から見たら糞みたいな目標だと思う。 指摘を受ける前に先に自ら言及しておくが、既に会社の本質と手段と目的を履き違えている。でも僕はそれで良いと思う。 そもそも僕の会社の主業務はツール開発だ。手段が目的であり目的が手段なのだ。 モリモリとやっていきたい。 体験は確実に大きな糧となる。 会社サイト 歩元株式会社 登記申請までのアクティビティ GitHub の Issues で管理している。 会社
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. (英語勉強しないと..) 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 (仕事でDeprecateとか滅多に使わんし) 同僚に聞きつつ10つあげてみた. 以下列挙 (例は実際の同僚やOSS上でのコミットメッセージです.) Add *A to *B AをBに加える
GitHub や Bitbucket などの Git ホスティングサービスの Hook や Webhook サービスを使って、Git に Push した時、自動的にサーバー側で最新版の master ブランチを pull するための PHP を拾ってきて、ちょっと改造しました。 2019年版を公開 最新版はこちらです https://ja.katzueno.com/2019/08/3712/ 更新: 2017年8月14日 旧バージョン 大きいプロジェクトであれば、きちんと Travis CI などのサービスを使いましょう。 ちなみに、Bitbucket では、5ユーザーまでの小規模プロジェクトであれば、無料で非公開 Git を作ることができるので、オススメです。 宣伝:ウェブサイトを作るCMS は concrete5 で決まり!(世界では、アメリカ陸軍、スイス政府、ミニクーパー等、日本でも
Hubot Advent Calendar 2014 14日目の記事です。 2014/12/13、リクルート本社で行われた Qiita API v2 Hackathon で、Chat 日報 なるワークフローを発表しました。 ありがたいことに、優秀賞をいただき、Kindle Voyage がいただける様です。 Hackathon のテーマ 今回の Hackathon のテーマは、Qiita APIv2を利用して毎日の開発が楽しくなるツールの開発 とのことでした。 開発は、ほっておいても楽しい ので、開発に当てる時間をより多く取れる様に、日報の作成を楽にする、という目的で開発しました。 作ったもの Qiita API v2 が発表されてすぐ、Hubot スクリプト hubot-qiita 開発に着手したのですが、業務内では別業務、業務外では CI2Go を作成していたので、未完成のまま塩漬けに
連載目次 連載第1回の「GitHub製フレームワークHubotの概要とインストール、チャットアプリと連携する基本的な使い方」では、GitHub社が開発しているBotフレームワーク「Hubot」の概要、Hubotとチャットとの連携方法、Hubotの基本的な使い方を紹介しました。 前回の「Redmine連携でチケットをチャットに通知&開発を楽しくするHubotスクリプト6選」と同じく、今回も、サンプルアプリケーションに対して修正を行うシーンを例に、Hubotと各ツールがどう連携するかを解説します。 ソースコードはGitHubそっくりなUIと機能を提供している「GitBucket」(Scala製)で管理し、ビルドやデプロイはCI(継続的インテグレーション)ツール「Jenkins」で行います。 利用したソフトウェアとバージョンは以下の通りです。 Hubot 2.4.7 Kandan 1.2 Git
市場関係者だけにとどまらない人気を博しているブログサイト「市況かぶ全力2階建」さん(以下、2階建さん)というのがありまして、殺伐とした金融の世界においてアレな話題を切り口にいつもほっこりとした時間を提供してくれています。 その2階建さんにTweetを引用される人の分布を調べてみたいと思い、ちょろっとコード書いて引用ユニーク数ランキングを作ってみました。 (12/14 15時 追記:同数の場合に同じ順位となる修正を加えて、結果を更新しました。) ついでに、そのコードをGithubにも置いて公開してみましたので、どんな作業してるかなどご参考になれば。(PHP 5.4以上にて) Github -yanoshin/kabumatome_analytics 以下、ざっとですが今回のルールです。 2階建さんの2014年中の公開記事を対象にしています。(現在、途中なので12月7日早朝時までが対象) 1記
Android Views http://www.androidviews.net/ Android ProTips: Blur Images Efficiently using Renderscript https://plus.google.com/+MarioViviani/posts/fhuzYkji9zz http://www.genymotion.com/ http://www.genymotion.com/ Flinto https://www.flinto.com/ Android Views http://www.androidviews.net/ Android Libraries Portal http://www.androidviews.net/category/libraries/ Android Snippets http://androidweekly.ne
β版 ソーシャルコンテンツプラットフォームとして注目を集めているGitHub。使いこなすにはまずgitを使えるようにならないと……と思って二の足を踏んでいる非プログラマの先入観を打ち砕くべく、gitコマンドもgitアプリも使わずにGitHubを使ったコンテンツ管理・コラボレーションを徹底解説。これでもうPull Requestも怖くない! β版について 本書のステータスは現在β版であり、現在、著者やレビュアの方々により追加・修正が行われている段階です。 いま購入されてお読みいただけるのはその途上の原稿を元にしたものです。 最終的に正式公開されたものもダウンロードしお読みになることはできますが、 正式公開版を読みたい方には今しばらくお待ちいただくことになります。あらかじめご了承ください。 概要サンプルリンク用タグ 関連サイト本書の関連ページが用意されています。 『みんなで使うGitHub』サ
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
Tokyo Otaku Mode(以下TOM)でエンジニアをやっているpchwです。 今回は情報共有ツールのお話をさせていただきます。 TOMの開発チームは、創業当初は数人で構成されていたのですが、最近ではフルタイムでないメンバーも含めてかなり人数が増えました。 少人数であればある程度自然に情報共有できるものの、人数が多くなってくると持っている情報量に差が出てきて、なかなかスムーズに共有を図ることができなくなります。 そこで頼りになるのが、情報共有ツールというわけです。現在、TOMの開発チーム内では情報共有のためにesa.ioというサービスを使っています。 なぜesa.ioを使うようになったのか? esa.ioとはどういうものなのか? esa.ioは他の情報共有プラットフォームと比べてなにが違うのか? これらの点を踏まえつつ、esa.ioを紹介していきます。ぜひ参考になさってください。 な
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル(dSYM)をアップロードする 5. 2のバイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く