子供を喜ばせながらプログラミングを続ける #childadvent | mah365
この記事は子育てプログラマ・ITエンジニア・Webデザイナー Advent Calendar 2015 10日目の記事です。 みなさん、こんにちは！ 1年ぶりのブログ更新になります。アドベントカレンダー参加をきっかけに、久々にブログを書いてみました。今回は子育てがテーマということで、双子の子供を抱えるプログラマとして何か書いてみようと思います。 僕を取り巻く環境 まずは家族構成の紹介と、僕の仕事について。 妻と双子の子供（男の子・2歳） + 妻の母親と一緒に暮らしています。 双子は幼稚園のプレスクールに通っていて、来年幼稚園に本格的に入園します。オムツが取れていなくて、ちょっと心配。 僕は今月の4日に32歳になりました。ソニックガーデンという会社で取締役として働いています。 このアドベントカレンダーの発起人の伊藤さんは同僚です！ リモートワーク主体の会社ですが、家だと集中し切れないことも多
大量レコードをINSERTするときに1回ずつコミットするのと最後にコミットするのとバルクインサート、どれが一番速いか | mah365
あらましと考察 テストデータを大量に作っては作りなおすときに、最初ふっつーにcreate!でデータを作ってた 重すぎて泣きそうになった Twitterで「毎回コミットしているからでは？」という助言をいただく そういうわけで毎回コミットするのとトランザクションで最後にコミットするのと、ついでにバルクインサートするの、どれが一番速いか試してみた いずれにしてもバルクインサートが圧倒的に速いが、あえて毎回コミットかトランザクションかで比較すると、100レコードか1000レコードぐらいのオーダーでは若干トランザクションが速い（誤差の範囲な気もするけど・・・）。ただし10000レコードのオーダーになると逆転する。 SQLiteはコミットの度にファイルに書き込む仕様のため、常にトランザクションが優位になると思ったら、そうでもなかった（参考：SQLiteデータベースのチューニング）。このあたりの挙動の理
Rubyで大きな配列から特定の要素を抜き出すとき、普通のselect使うのとLazyのselect使うのどっちが速いの？ | mah365
多分Lazy使ったほうが速いんじゃないかと思ってベンチマークしてみました。 ただし状況による ハッシュの配列から、ハッシュ内に特定のキーワードを持つハッシュを抽出するという処理で比較してみました。 というわけでまずは抽出したものを全件Arrayのインスタンスにしなおすという処理の結果から。
OS X YosemiteからJSでMacアプリを作れるようになったって！？と聞いてみたものの | mah365
次期MacOSXのYosemiteからAutomationをAppleScriptではなくJavaScriptで書けるようになったというのは聞き及んでいましたが、Macアプリも作れるようになっていたとは知りませんでした。 どんな感じで書くの？ というわけでBUILDING OS X APPS WITH JAVASCRIPTという記事にチュートリアル形式でJavaScriptを利用したMacアプリの作り方が書いてあるので、詳しくはそちらを・・・といきたいと思ったのですが、 // 注：ウィンドウを表示するだけのサンプルコード ObjC.import("Cocoa"); var styleMask = $.NSTitledWindowMask | $.NSClosableWindowMask | $.NSMiniaturizableWindowMask; var windowHeight = 8
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
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を呼び出すよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
