dev.toがなぜinsanely fastを実現出来ているか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいな
ConoHaとさくらのVPSにdokku-altを入れて、ブログと開発環境を柔軟に
ConoHaとさくらのVPSにdokku-altを入れて、ブログと開発環境を柔軟に posted at 2015-05-17 18:10:53 +0900 by kinoppyd Dokku-alt をConoHaVPSに入れて、個人PaaS環境を充実させた話 このブログは、今のところさくらVPSのWebインスタンスと、ConoHaVPSのDBインスタンスで動いている。動いてはいるが、さくらVPSの方が3年くらい前に右も左もよく分かってない状態で立ち上げたNginx+Apache+Wordpress構成で、いい加減メンテが不可能な状態に陥っており、Wordpressのバージョンを上げることすらままならなくなっていた。 そこで、さくらVPSのインスタンスを一回全部消して、Ubuntu+Dokku-altを立てて、そこでブログをはじめとするいろんな開発環境を集約してしまおうと考えた。 まずはC
形態素解析エンジンMeCabにて文章中から短歌を抽出 - inaniwa3's blog
概要 偶然５７５７７になっている文章を短歌としてつぶやく Twitter の bot を作りました。 フクロウが鳴くと明日は晴れるので洗濯物を干せという意味 #tanka ウィキペディア日本語版「フクロウ」より http://t.co/Dm1uHcQdzR— 偶然短歌bot (@g57577) 2014, 12月 31 再帰的アルゴリズムが有効な問題として有名であり #tanka ウィキペディア日本語版「ハノイの塔」より http://t.co/vm2ZqwImKi— 偶然短歌bot (@g57577) 2014, 12月 31 文章はウィキペディア日本語版を対象としました。 作り方 jawiki-latest-pages-articles.xml.bz2 をダウンロード。 WP2TXT で上記を扱いやすい形式に変換。 このスクリプト で５７５７７になっている文を抽出。数時間かけて（遅い）
PythonとMongoDBとPolymerでRSSリーダーを作った
PythonとMongoDBとPolymerでRSSリーダーを作った Pythonで何かアプリ書きたいなと思ってはいたので、RSSリーダーを作った。フレームワークは薄いやつが良かったのでFlaskを、データはMongoDBに突っ込んでいる。 Flask + MongoDBのところまで実装して暫く放置していたけど、最近思いつきでPolymerをねじ込んだので記事にしてみる。 やってること スケジューラでopmlに登録してあるRSSから記事を取得しMongoDBに保存 トップページで50件ずつ記事の表示 & 非同期で50件づつ取得 購読しているRSSで表示する記事をフィルタ Opml(XML)のパース→記事の取得 に非常に時間が掛かるので、データストアに入れておいてそこから取得しないとRSSリーダーとして非実用的。この定期的な取得処理をHeroku Schedulerで実行している。あと遊び半
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tutorial & Screencast: Java on Heroku with Eclipse
