お久しぶりです。この1ヶ月、フィリピンでは地震あり、台風ありと、厳しい天災に見舞われ、僕もこの1ヶ月で2度ほどセブへ足を運びましたが、幸いにも大きな被害はなく無事に営業を続けることができております。 色々とご心配していただいた方々、お心遣い誠にありがとうございました。ただ、近隣の島々では、非常に根深い被害がありますので、フィリピンに会社を持つ我々として、何かできることを考えていきたいと思っております。 次期開発に向けてエンジニアを募集。 さてさて、ラングリッチも去年の夏に東京オフィスを構えてから、早いもので1年が経過しましたが、お陰様で無事に営業を続けております。 そんな中、秋頃から新しい事業もスタートし、来年に向けて開発がなお活発になるため、ここらで僕らと一緒に開発をしてくれるエンジニアを募集したいと思います。 というわけで、まずは会社の特徴を紹介します。 ラングリッチは『オンライン英会
“[ ]”などを個別に読む場合はleft/open bracket, right/close bracketと読んでください。 “<“はless than、”>”はgreater thanとも読みます。 Dave Thomasは”<<“を”less than, less than”と読んでいました。 “-“がdashなのかminusという話しについては、The difference between a dash and a minus signを参考にしてください。 あまり、この読み方はしないよ!とか、私はこう読むよ!とかあれば、@masuidriveまでmentionください。 [2013/11/21 14:00:00] 色々な方々にコメントを頂き追加しました。 速く・正確に読む ITエンジニアの英語 ITエンジニアの ゼロから始める 英語勉強法
RailsにはActiveRecordという素晴らしいORマッパーが付属していますが、 パフォーマンスの問題とか複雑な処理とかで やっぱり直接SQL実行したい…って場面多々ありますよね。 私SQL直接実行するコマンドって 「execute」しか知らなかったんです… で、executeで実行すると 結果が何か「Mysql2::Result」みたいなクラスのオブジェクトで返ってきて 使いづらいんです… (Mysqlの場合) $ ActiveRecord::Base.connection.execute("select * from users where age > 20")いちいちeachで値を取って整形したりして… 上記のようなselect文の結果なら、モデル経由で取ってくる時みたいに 配列とかで返してくれれば… とか思ってました。 そしたらやっぱりあった(゚д゚)! 〜参考になりました!
さきほど帰国。parse.comのメモに引き続き、re:InventでのLogglyのセッションについてもまとめておく。 【追記 2013/11/20 9:20】スライドがupされていたので貼っておきます。 要約すると、 お客さんから大量に送られてくるログをリアルタイムに捌くためのシステム 最初の設計ではSolrCloudを利用していた 第二世代ではElasticsearchを利用。システム全体としてElasticな環境に。 基本環境はKafka + Stormな構成 セッションの情報は以下のとおり。 ARC303 - Unmeltable Infrastructure at Scale: Using Apache Kafka, Twitter Storm, and Elastic Search on AWS This is a technical architect's case stu
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
最近引っ越しました。 UR都市機構とか賃貸ならJKK東京【東京都住宅供給公社】とかいろいろ見ましたが、これだ!と思う物件に出会うのはなかなか大変ですね。 都内での引っ越しは3度目だったのである程度慣れてはいましたが、定価?から8,000円も家賃が下げれたことに驚いたので、知ってる人からすると当たり前や!と思うかもしれませんが、忘れないように書き留めておきます。 家賃を下げれた要因 今回家賃を下げれた要因は、取引態様が専任媒介であったためだと思います。 専任媒介とは、ザックリ言うと、不動産屋で管理・所持している物件です。 大家と不動産屋の距離が近いので、交渉が捗ります。 僕が出会った不動産屋さんは、マンションのオーナーとは、もう20年以上の付き合いになると言ってました。 たしかにそんなに長く付き合ってたら、交渉もし易いですよね。 探し方 webで部屋を探します。 取引態様の欄に、仲介とか専任
渡辺です。 最近はユニットテストの導入方法などに関するエントリーが多かったので、今回は実用的な小ネタとして、メソッドにおけるパラメータの正当性検査とユニットテストについて紹介したいと思います。 パラメータの正当性検査 はじめにパラメータの正当性検査について復習しましょう。Javaプログラマであれば読んでないことが許されないEffective Java(第2版P.175、ただし絶版)には次のように記述されています。 ほとんどのメソッドとコンストラクタは、パラメータとして渡される値に関して何らかの制約を持っています。たとえば、インデックス値が負であってはいけないとか、オブジェクト参照がnullであってはいけないというのが普通です。このような制約は明確に文書化すべきであり、メソッド本体の初めに検査することで制約を強制すべきです。これは、エラーが発生したらできるだけ速やかにエラーを検出するようにす
GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
この前、10 年以上前に趣味で作っていたフリーソフトについてメールで質問が来た。もはや完全に記憶から消えているだけでなく、いま使っている PC にソースコードもない。何も分からない、答えられない。 そのままでは古いソースコードも成仏しきれない。供養するために、古い HDD を引っ張り出して探したところ、自宅サーバーをやってた HDD の中に CVS レポジトリーが見つかった。せっかくなので、Git に変換して GitHub で公開してみた (その1, その2)。これで成仏できるだろう。 そこで、この記事では CVS レポジトリーを Git に移行した手順をまとめておく。レガシーな CVS から Git に移行したい人の参考になるとうれしい。 git cvsimport の使い方 Git には git-cvsimport というコマンドがある。CVS の履歴を Git に変換してくれる。 C
import flask.ext.whooshalchemy # set the location for the whoosh index app.config['WHOOSH_BASE'] = 'path/to/whoosh/base' class BlogPost(db.Model): __tablename__ = 'blogpost' __searchable__ = ['title', 'content'] # these fields will be indexed by whoosh id = app.db.Column(app.db.Integer, primary_key=True) title = app.db.Column(app.db.Text) content = app.db.Column(app.db.Text) created = db.Column(db
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く