グリー、エンジニアの採用に新ツール「GREE Programming Challenge」を導入
グリーは、エンジニアの採用にあたって、従来のWebエントリーや書類選考と並行して、プログラミングの実技に重点を置く「GREE Programming Challenge」を1日から採用するとともに、今夏より世界各国の開発スタジオにおけるエンジニア採用にも順次導入すると発表した。 「GREE Programming Challenge」は、米InterviewStreetが運営するサービスを利用したもので、同サービスはアメリカにおいて数多くの情報技術、インターネットサービス関連企業に採用され、エンジニアの選考プロセスにおいて高い評価を得ている。なお、グリーは同サービスをはじめて導入した日本企業となる。 応募者は、従来の書類選考と一次面接に参加する代わりに、コーポレートサイトにアクセスして、出題されたプログラミング問題を一定の時間内で回答する。プログラミングの途中経過はすべて記録され、問題解決
デバッグビルドとリリースビルドで処理を変える方法（2）
デバッグビルドとリリースビルドで処理を変える方法その２です。 以前に書いた方法は以下から。 デバッグビルドとリリースビルドで処理を変える方法 http://neta-abc.blogspot.jp/2012/02/blog-post.html ADT 17（らしい）から/genの下にBuildConfig.javaが自動生成されるようになっています。 BuildConfig.java /** Automatically generated file. DO NOT MODIFY */ package com.example.builconfigtest; public final class BuildConfig { public final static boolean DEBUG = true; } このBuildConfig.DEBUGはリリースビルド時（Export Signed
android:debuggableでデバッグログ切り替えはやめた方がいい - ReDo
AndroidManifest.xmlのapplicationタグ指定する、android:debuggable属性によるデバッグログのON/OFF切り替えをしばしば見かけるのですが、SDKで警告が出るのもあって公式としては非推奨ぽいので、少し動作について調査してみました。 以下、検証コードと詳細。 ○結論 原則使わないのが望ましいです。書き換え忘れもありえますし、開発時のapkと公開時のapkが別であることは色々な不幸の元です。 やむを得ず使いたい際には独自staticがまだマシだと思います。 public class MyConfig { public static final boolean DEBUG = true; } ○android:debuggableの動作 以下の様なアプリを作って試してみました。（SDKr18, ADT18.0.0） package test.debug
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ キーマンズネットは、IT担当者を対象にしたアンケート結果として「テスト自動化ツールの導入状況」を公開しました。 それによると、導入済みは全体の8.5％（「既に導入済みである（追加リプレイスなし）」7.5％と「既に導入済みである（追加リプレイスあり）」の1.0％の合計）で、導入を検討しているが4.8％。今後も導入しないするグループは86.7％（「必要性を感じているが導入を検討していない」の38.6％と、「必要性を感じない」の48.1％の合計）」になりました。 グラフを見ると従業員規模1001名以上では導入済みが約15％である一方、100名以下では1.8％であり、従業員規模によって大きな違いがあることが分かります。 対象言語はJavaがトップ、目的は品質の向上、工数削減など すでにテスト
MySQLをさらに理解するために読んだ記事まとめ - $shibayu36->blog;
最近MySQLの勉強をしていました。実践ハイパフォーマンスMySQLを読むべきという話を聞いていたのですが、かなり網羅的に書かれていて、今の知識ではどれが重要なのかわからない状態でした。そこで色々調べてみて、参考になる記事をいくつか見つけたので、少しまとめてみようと思います。 今回まとめた記事を読んで、大体以下のことが理解できました。 インデックスの使われ方とその構造(MyISAMとInnoDB) EXPLAINの詳しい使い方、見方 InnoDBの特性 ALTER TABLEの特性 レプリ遅延 まず最初に Webエンジニアのための データベース技術[実践]入門 (Software Design plus)posted with amazlet at 12.06.02松信 嘉範 技術評論社 売り上げランキング: 9767 Amazon.co.jp で詳細を見る 松信さんの書いた「Webエンジ
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
全プログラマーが知るべきレイテンシー数
Latency numbers every programmer should know — Gist L1キャッシュ参照 0.5ナノ秒 分岐予測失敗 5ナノ秒 L2キャッシュ参照 7ナノ秒 Mutexのロックとアンロック 25ナノ秒 メインメモリー参照 100ナノ秒 Zippy[Snappy]による1KBの圧縮 3,000ナノ秒 1Gbpsネットワーク越しに2KBを送信 20,000ナノ秒 メモリーから連続した1MBの領域の読み出し 250,000ナノ秒 同一データセンター内におけるラウンドトリップ 500,000ナノ秒 ディスクシーク 10,000,000ナノ秒 ディスクから連続した1MBの領域の読み出し 20,000,000ナノ秒 パケットを、カリフォルニア→オランダ→カリフォルニアと送る 150,000,000ナノ秒 Jeff Dean著(http://research.googl
パナソニックを退社しました
5月31日で、2年とちょっと働いたパナソニックを退社しました。最初半年ぐらいは研修だったので、実質1年半ぐらいで辞めたことになります。 辞めた理由はシンプルで、私はソフトウェアの開発がしたかったのですが、実際にはソフトウェアの開発が出来なかったこと。それから、社内の雰囲気が合わなかったことです。 もし今就活中、または来年就活の方で製造業を志望されているソフトウェアエンジニアの方がいたら参考になるかもしれませんので、少しだけ書いてみます。 ただ、大きな会社なので、部署によっては全然雰囲気が違うようで、楽しく仕事をしているところもあるようです。たまたま、私が合わなかっただけです。実際離職率は低めです。 それから、仕事の方針にはミスマッチはありましたが、部署の皆様には大変お世話になりましたし、私の考えに共感して助けてくださることもありました。特定の方を非難する意図はないことを申し添えておきます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
