そろそろJavaみなおしてもええんやでRubyist started to learn Groovy - things important to leran new LL
検査メニュー | 遺伝子検査・DNA検査のMYCODE（マイコード）
遺伝子検査 MYCODEの各検査キット、有料オプション等の販売を停止いたしました。詳しくはこちらをご確認ください。 MYCODEの遺伝子検査は、がんなどの病気のかかりやすさから、長生きや肥満など体質の把握など、様々な項目について遺伝的傾向をお調べします。 DNAからご自身の持つリスクと可能性を把握し、生涯の健康管理にお役立てください。
機械に叱られるって幸せじゃないっすか？ - YAPC::Asia Tokyo 2014
本トークではプロジェクト・プログラムの品質を担保する為の自動化および機械化にまつわる話をある程度の範囲に渡って行う予定です． ソフトウェアの品質を向上する為には様々な方法がありますが，その中には効果的であっても人間がやるべきではない仕事というものが存在します．それは例えば，未使用の定義済み変数の検出であったり，コードスタイルの統一であったり，バグが潜んでそうな部分にあたりを付ける作業であったりするでしょう．あるいはブラウザをポチポチするという修行かもしれませんし，ソフトウェアテストを忘れずにpush前に回す，というようなことかもしれません． そうした，人間が心をこめてやるべきではない仕事はコンピュータにアウトソースして人間の代わりにやってもらい，何か問題があったら機械に叱ってもらって，該当部分を修正することで品質の向上を実現していく，機械に叱られるってマジサイコー！！ といった事について話
Go For Perl Mongers - YAPC::Asia Tokyo 2014
しばらくGoを書いてきて、GoはPerlを使っている人たちにとってとても相性のよい言語だと思うようになりました。 Perlでは手が届かないかゆいところに手が届くし、速いし、バイナリを作って設置するのも簡単です。 しかしながらGoを書き始めるにあたっては多少それまでPerlや他のLLで培ってきた考え方を変える必要があります。 本トークでは、Goを多少触った事があるけれどもまだちゃんと「Goのやりかた」をつかめてないというPerl（もしくはLL系）の方を主な対象としてGoを書く際に知っておきたい知識を具体的な実例を交えて紹介します。 できれば、下記のトピックだけでなく、会場で具体的な質問なども受けたいと思っていますので、もしこのトークが採択されて聞きにきていただける場合はぜひ質問を持ってきて、大声で聞いてください。 goroutineのコントロール (or, "Forget about POS
いろんな言語を適材適所で使おう - YAPC::Asia Tokyo 2014
サービスを提供するシステムがますます複雑化していく昨今、そのための問題解決に用いられるプログラミング言語の選択肢もまた、多様化しています。そのような中で、Perlに関しても私たちひとりひとりのユーザにおいて、その位置付けを見直し続けているという現状ではないでしょうか。 本トークでは、全社的に使用するアクセス解析システムを開発する上で、システムを構成する個別の下位問題がどのような問題であるのかに応じて、Perl, Ruby, PHP, JavaScript, Go, Puppet等、どのようにして適切な言語やツールを選択、使用してきたかを説明します。 その結果として、本トークをお聞きになられたみなさまが、これからのサービス/システム開発における現状と、問題解決のための適切な技術選択とに対する、なにかしらの示唆を得ていただけると幸いです。
Dockerで遊んでみよっかー - YAPC::Asia Tokyo 2014
インフラの自動化、Immutable Infrastructure、新しいアプリケーションのデプロイ方法、Dockerを支えるLinuxのコンテナ技術などなどDockerは各方面でかなり盛り上がっています。先日のDocker Meetup Tokyoにも数百人の参加応募が集まることからも注目の高さがわかります。 ただ、その盛り上がりとは別に、Docker自体リリースされてそれほど長い時間が経っているプロダクトではないことから、どのようにDockerを使ったらよいのか、アプリケーションを動かすベストプラクティスがまだ定まっていないように思えます。 このトークはDockerをまずはとにかく手元や開発サーバで動かして、試して遊んでみようというセッションです。 遊ぶからにはDockerで"Hello World"を出して終りではなく、もう少し便利なこと、例えば身近な作業の自動化やちょっとしたアプリ
そんなにビッグでもないデータ処理手法の話 - YAPC::Asia Tokyo 2014
ビッグデータという言葉が取り上げられるようになって久しいですが、実際どういう処理をどういう方法で実現するの、という総括はあまり行われていない気がします。 このトークでは、ペタバイト級データはちょっといま手元にないんで、という人のために、GB級からTB級までの「あんまり大きくないデータ」に着目して、近年充実してきた手法およびそれを実現するミドルウェア・プラットフォーム・フレームワークを紹介し、またそれらの中でPerlやその他の言語がどう使われているかをざっくりと解説します。
インフラエンジニア(狭義)は死んだ - YAPC::Asia Tokyo 2014
※ 本トークにおける「インフラエンジニア」は、運用エンジニアでありながら、プログラミングに関連すること一切を、自らの選択によって放棄してしまっている人を指します IT系エンジニア(広義)を世代ごとに分類すると、おおまかに以下のようになると思います。 ハードやネットワークなどの低レイヤからミドルウェアの設定、コーディング、運用まですべてを担っていた第一世代 第一世代の知識経験を備えつつ、効率化のためにレイヤごとに分業をするようになった第二世代 分業前提で業界に飛び込んだ第三世代 もちろん、所属する組織の規模などによって一概には言えないですし、第二世代第三世代でありながら、幅広い領域をカバーしつつ活躍しておられる方もたくさんいらっしゃるとは思いますが、大半は世代や年齢層ごとにどこかに心当たりがあると思います。 昨今はフルスタックエンジニアなる言葉がバズワードとなり、下から上まで一人でなんでもこ
Go で利用できるプロファイリングツール pprof の読み方 - Qiita
概要 Go にはプロファイリングツールがついているのだけど，何を出力してくれているのかよく分からなかったのでメモ．間違いに気づかれた方いらっしゃったらコメントいただければ幸いです ． 出典 Russ Cox さんが下記に書いてくれてました．これを読むのが間違いないです． Russ Cox, Profiling Go Programs CPU Profiling プロファイリング用のコードの埋め込み まず， runtime/pprof を import しておきます．(net/http/pprofというのもあります)． CPU Profiling は計測したい実行コードの前でStartCPUProfile()を呼んで，計測終了のタイミングでpprof.StopCPUProfile()を呼びます．終了の方は defer に登録しておけば関数抜けるときに自動で呼ばれるので便利ですが，Ctr-Cと
Facebookの数千台規模のmemcached運用について - ゆううきブログ
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関するトップレベルのカンファレンス。 Scaling Memcache at Facebook Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani NSDI'13 In Proceedings of the
寿司ゆきがぬいぐるみになるんだよ - はてゆき
本業を見失いつつあるあわゆきです。 標題でほぼすべてですが、ご報告です。 LINE クリエイタースタンプでおなじみの寿司ゆきが、なんとぬいぐるみになります。なにそれすごい本人がいちばんびっくりだわ！ スタンプを発売してから割と間もない頃、プライズメーカー*1のシステムサービス株式会社さんからお声かけいただき、じわじわとお話を進めてきました。 しがない受託フリーランスのフロントねんどエンジニャーにはまったく縁のないお話だったので、舞い上がりつつ、テンパりつつ。それはもう黙っているのにも必死のパッチでした（喜怒哀楽のマスキングが不自由かつ、何かあるとすぐに人に言いたくなる）。 そして昨日、打ち合わせでお会いした時に言ってもいいよ！と快諾いただいたので、晴れて公言できることになりました。はー、よかった！ 三面図 vs フロントねんどエンジニャー 立体になるわけなので、三面図というものをはじめて作
有能なウェブエンジニアをウェブディレクターにすることについて - 下林明正のブログ
ありがちな話なのでこのことについてふと考えることが多い。 最初に断っておくと特に結論はなく、ケースバイケースで考慮するべきというのが僕の考え。 それを踏まえて、先ずは良い点について考えてみる。 一番もっともらしい理由は、他のエンジニアが納得しやすいこと。一番戦闘力の高いエンジニアがエンジニア長になって皆を束ねていくという世界観。若く猛ったエンジニアも従ってくれるけど、石器時代っぽい。 次点として、システムの実装を把握しているのであまり滅茶苦茶なことにはなりづらく、安心して任せられるということ。 それ以外にありがちなものとしては、人的コストの圧縮も考えられる。人件費もそうだけど、頭数が1つ増えるだけでコミュニケーションパスは爆発的に増加していくのでコミュニケーションコストの削減にも繋がる。 次に悪い点について考えてみる。 これはまさにピーターの法則そのもので、組織の構造的な欠陥を示している。
チームの想いをなんでも共有する「ゆるふわ」「ポエム」タグが議論のきっかけに - freee株式会社 Qiita Teamインタビュー - Qiita Blog
チームの想いをなんでも共有する「ゆるふわ」「ポエム」タグが議論のきっかけに – freee株式会社 Qiita Teamインタビュー こんにちは！ htomineです。 みなさんのチームには「気兼ねなく情報発信できる場所」はありますか？ 今回は、Qiita Teamをそんな場所としてご活用いただいている、freee株式会社さんの事例をご紹介します。 サマリーポイントをまとめると使い方の指針になるような記事をはじめに投稿してから徐々に広めた開発ドキュメントにかぎらず、仕事のフローの改善案、自分の想いやライフハック的な記事など、メンバーに伝えたい様々な情報を投稿してよい場所として使っている目次freee株式会社Qiita Team導入の経緯導入前の課題使い始めてみてどうだったか―どんな記事が投稿されていますか？―社内に広まるきっかけは何だったのでしょうか？今までのツールではこういった投稿はでき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.yoslab.com/entry/2014/07/09/202304
このページを見るには、ログインまたは登録してください