知っておきたい！Herokuを使う上では当たり前？の16の常識 | mah365
Herokuの公式ドキュメントは英語なので読みづらいですよね。herokaijp/devcenterのように、有志が日本語訳してくれているドキュメントもありますが、その中でも特に抑えておきたい16個の常識について挙げてみました。（16日に公開する予定の記事なので、何となく16個挙げてみました。。） （補足）Herokuを使う上での登場人物の名前 Dyno 「だいの」と呼びます。1Dynoと言ったとき、一つサーバが立ち上がっているようなものだと考えて下さい。 Routing Mesh Herokuアプリにアクセスがあったときに、Dyno間の負荷をロードバランスしながらリクエストを振り分ける機構をRouting Meshと呼びます。たまに「Router Error」というログを吐くのですが、そのとき障害が起こっている場所はここです。 常識1. Dynoは1時間アクセスがないとアイドル状態になる
Writing Fast Rubyというスライドが良い | mah365
ちょっとしたコードの書き方でパフォーマンスが変わることがあります。リーダビリティを重視する向きからすれば小手先のテクニックに映るかも知れないのですが、リーダビリティを維持しながらちゃんとしたパフォーマンスを出すためにも、テクニックを知ることは大事なことだと思うのです。 結構違うもんですなー というわけで、そんなテクニックをまとめたスライドがWriting Fast Ruby。見ていて参考になったのでメモ。 たとえば引数に&blockをとってcallするよりも、yieldの方が5倍速い、とか、 def slow(&block) block.call end def fast yield end mapにブロックを渡すよりも、シンボルを渡す方が20%速い、とか (1..100).map {|i| i.to_s} (1..100).map(&:to_s) mapしてからflattenを呼び出すよ
コードレビューで大事なのは、読めないコードを「読めない！」と言える勇気だと思う | mah365
一見読めないコードでも、「読めない」と言うと何だか負けた気になって、頑張って読んでコメントしようと思ったりしますよね。しませんかね。でも、コードレビューで大事なのは読めないコードを「読めない！」と言える勇気だと思います。 当たり前だけど、読めないコードが負債化する 読める、読めないというのには、まずスキル的な観点もあると思います。スキルがないと、そもそも読めない。技術不足から「このコードを読めない俺のスキルをまず疑う」と考えて「読めない」と言えないケースがあります。 その裏返しに、スキルがあるので読めてしまうというケースがあります。「ああ、そういう風に書くのね」「まぁ、もっと良い書き方がある気がするけど・・・」しかしスキルがある人が読んだ場合、スキルがある人は良い書き方も知っているので、「ちょっと読みにくくない？」とコメントすることは、ままあります。つまりスキルがある人は「読めない」と言え
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
HerokuにPerformance Dynoなんてものが追加されていることを今日知った | mah365
HerokuにPerformance Dynoなんてものが追加されていることを今日同僚から聞いてはじめて知ったのですが、こちらのtechcrunchの記事によると、2014年の2月には既にあった模様。滅多にDynoの設定クリックしないから、気付かなかったわー。 料金は通常のDynoに比べて16倍界王拳 2x Dynoが2倍界王拳だとすると、Performance Dynoは16倍界王拳です。 1x Dyno: $0.05/hour 2x Dyno: $0.10/hour Performance Dyno: $0.80/hour 1ヶ月起動し続けると720時間なので、それぞれ 1x Dyno: $36（日本円にして約3,900円） 2x Dyno: $72（日本円にして約7,800円） Performance Dyno: $576（日本円にして約62,000円） という感じで、1ヶ月間起動す
iOS8はiOS7に比べてDOM操作が3倍早い | mah365
Apple Shows Love for HTML5 with iOS 8という記事でiOS7のときと比べてiOS8のWebのフロント処理能力がどれほど向上しているかをSenchaがまとめています。結論としてはiOS8からHTML5に本気を出せる。 やっとHTML5が火を噴くのかな 具体的なベンチマークなどはApple Shows Love for HTML5 with iOS 8をご覧頂いた方が良いと思うのですが、DOM操作のパフォーマンスが大幅に向上している点などを考えると、どうしてもタップしてからの動作がイマイチもっさりだったHTML5アプリがようやく火を噴くのかなと思います。 Swiftの登場で格段にネイティブアプリのコーディングの敷居が下がったiOSではありますが、マルチデバイスへのリリースにはどうしてもHTML5に軍配が上がりますもんね。 そう考えるとCordovaのいち早いi
テキストエリアには極力、文字数制限をつけてはいけない | mah365
常々思っていることなのですが、テキストエリアには極力、文字数制限をつけてはいけないと思うのです。 テキストエリアに長文を書くユーザーは、大概何らかの衝動に駆られている 登録時に「ご意見ください」というテキストエリア 解約時に「どんな理由での解約ですか？」というテキストエリア テキストエリアというのは大概は任意のフィールドで、それでもあえて何か書こうと思うユーザーというのは、大概何らかの衝動に駆られていると思うんですよね。 登録時に書くような人なんていうのは「超応援してます！将来的にはこんな機能に対応して欲しいです！」という衝動に駆られている訳ですし、解約時に理由を書くような人なんていうのは「ここがダメだった。あそこがダメだった。二度と使わないけど、フィードバックとして書いておくよ」という衝動に駆られている訳です。 で、衝動に駆られて書いた結果、システムから「400文字以内でお願いします」な
Chromebookの普及がしたら、という未来を想像するとワクワクを隠し切れない | mah365
Acerから新しいChromebookが今年の9月から出荷されるらしい。安いだけがウリかと思っていたChromebookだけれども、この新しいChromebookを見て、少し考えが変わった気がする。 Acer Chromebook 13の特徴 まずAcerから新しく出荷されるChromebook 13の特徴を列挙してみたい。 低解像度1366×768モデル SSD 16GB / RAM 2GB / 13時間連続駆動可能 / 約2万9000円 高解像度1920×1080モデル SSD 16GB / RAM 2GB / 11時間連続駆動可能 / 約3万円 高解像度1920×1080ハイスペックモデル SSD 32GB / RAM 4GB / 11時間連続駆動可能 / 約3万9000円 CPUは全ラインナップ共通でNVIDIA Tegra K1（クアッドコア2.1GHz）。本体サイズは幅x奥行き
英語の学習サービスに何故飽きてしまうのか | mah365
学習サービスに飛びついては飽きてしまう今日この頃ですが、飽きた飽きたばっかり言っててもしょうがないので理由を考えてみました。 やったところで普段自分が読んでいる英文が読解できるようになる訳ではない 例えばrails-coreメーリングリストの英文が爆速で読めるようになる訳でもない。 英語の学習サービスを使っている時間が勿体無く感じてくる 効果が出ないのでつらくなる。 単語も普段使わないものばっかりなので、活かす機会がやってこない 普段読むの、技術文章ばっかりだしね。フィリピンパブにでも行けば良いのかしら。 一般にある英語学習サービスは英文読解力を向上させるために絞られたものではなくて、むしろ英会話力にフォーカスしていると思うので、僕のニーズとそもそも合っていない、というのはあると思います。 ただ英語も言葉なので、所属しているクラスタが違うと単語が違うのも事実。日本語でもネト充とリア充とでは
テストしにくいコードは、嫌なコード | mah365
来週話すクソコードに思いを馳せる毎日ですが、クソコードと言うか、嫌なコードだなと思うコードの一つに、テストしにくいコードがあります。 テストできないんじゃどうしようもない アプリを開発していてテストできないというのは、もう、なんというか、どうしようもない状態な訳です。 「テストコードがないコードをレガシーコードと呼ぼう」を合言葉にレガシーコード改善ガイドという本すらあります。この本で語られているのは、テスタビリティの欠片もないコードを、何とかテスト可能なように改良してテストを追加するテクニックです。そのテクニックだけで472ページにも及ぶ大型本が書けてしまうのですから、テスタビリティのないコード恐るべしという感じです。
ニーズの本質を考える | mah365
ニーズ＝要望なのだけど、要望をストレートに実現しても、そのまま満足につながらないことがある。 ニーズはあくまで言語化されたもの というのも、ニーズは「こうなったらもっと良いのに」と思った結果であって、そう思った原因、問題の本質を表現しているわけではないから。つまり真の解決策を得るためにはニーズの本質を考える必要がある。 こういったニーズの本質を考える習慣、技術というのは、いつもやっていないとなかなか身につかないものだと思われる。気を抜くと「そう言われているんだから、その通りやろう」と思ってしまう。ニーズの本質を考える姿勢というのは、ニーズを伝えた当人からすると「なんですぐやってくれないの」という不満につながることもあるからだ。 だからこそスピーディーに本質を探れるように技術を高める必要があるし、技術を高めるためにも習慣化する必要がある。大変だけど、重要なことなんですよね。
コーディングスタイルガイドをみんなで議論するということ | mah365
コーディングスタイルガイドとは、ある言語、あるフレームワークを使用するときに守る、コードの書き方のガイドのようなものです。システムに対してより抽象度の高い表現が可能になった昨今、コーディングとはシステムにおける設計そのものであり、コーディングスタイルガイドはその設計を支える標準化の仕組みと言えるでしょう。 コーディングスタイルガイドはシステムの品質を支える源泉 チームでコーディングスタイルを合わせるのには重要な意味があります。何より他人のコードが読みやすくなるし、読みやすければ表現したい処理に対してコードが妥当かどうかチェックするのに時間がかからない、つまり品質とコスト（時間）を両立して改善することができます。 ところでコーディングスタイルは随時進化するものです。使用している言語で表現できることもバージョンを重ねるにつれて広がっていきますし、何よりチームが時間を重ねるにつれて成長しています
自動的にEager Loadingしてくれるようになる「Goldiloader」というGemが良い感じ | mah365
RailsでのDBへのクエリの組み立ては常にN+1問題との戦いですよね。N+1が発生すると大幅にパフォーマンスがダウンしてしまうので、適切な事前ロードをいかに行えるかがプログラマの腕の見せどころになります。 でもそれって本質でしょうか？ DBにクエリを投げる部分の実装の詳細なのでは？ クエリが空気読めばいいじゃん！という「Goldiloader」 「それって実装の本質じゃないよね。詳細だよね。それはクエリを投げる部分（ActiveRecord）が空気読めばいいんじゃね？」 そんな思想で現れたGemがGoldiloaderです。Gemfileに加えるだけで勝手にEager Loadingしてくれるようになります。 このGemをbundleせずに以下のコードを叩くと、eachでpostsが呼ばれるたびにロードを繰り返してしまうのですが・・・ > blogs = Blogs.limit(5).t
自分がメンテしないコードの品質を上げようとするわけがないよね | mah365
先日、リーダブルなコードを保つためには、コードが読まれるような文化をつくらなければならないのではないかというエントリを書いたのですが、こんなことを思ったのもある思い出話があったからでした。 「どうしたらこんなコードを納品できるの！？」 僕にとってのはじめてのオフショア。外部設計書を書いて「これ作ってねー」と海の向こうへ投げるだけの簡単な仕事を引き受けまして、設計書を投げた後、いい感じの時間が過ぎた頃に「どれどれ」とコード（PL/SQL）を見てみたのですが、 「このプロシージャ、すごく・・・長いです・・・」 ・・・うーん、外部設計書の章単位でプロシージャが区切られています。 確かにまぁ、設計書通りっちゃ設計書通り。 しかしいろんなプロシージャ間での処理が書かれていてDRYじゃない。共通の設定を読み出すところもハードコードされているので、仕様変更したいときに死んでしまいそう。 「どうしたらこん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apple PayにもHuman Interface Guidelineが出ていた | mah365
Railsでの開発はテストを腐らせたら死ぬ | mah365
好みの指摘と、品質の指摘 | mah365
素早く価値を届けるには、届ける価値の本質を見失わないこと | mah365
お、楽天から新しいサービスが出てる、と思ったらアフィリエイト促進サービスだった | mah365
どの時間帯にツイートすると一番反応良いかをざっくり調べる | mah365