エンジニアの立ち居振る舞い: ボトルネックを作らないように - skozawa's blog
お題「エンジニア立ち居振舞い」 僕が意識しているエンジニアの立ち居振る舞いは、チーム開発におけるボトルネックをなるべく発生させないようにすること。 エンジニア、デザイナー、企画、ディレクターなどがいるチームで開発していると、エンジニアリングやサービス仕様の側面で困りごとが発生することがある。 例えば、 チームのエンジニアが仕様や設計について困っている。 チームのエンジニアがレビュー待ちでタスクが進めづらくなっている。 デザイナーの開発環境でエラーがでたり、gitの操作で困っている。 企画、ディレクターなどがエンジニアリングに関して相談がある。 比較的チームに長く在籍していて、サービス仕様などに詳しいということもあるけど、こういったエンジニアリングにおける困りごとをなるべくすばやく解決できるようにして、待ち時間を短く、チームの開発効率を上げようとしている。あとは、一人でできるタスクよりも複数
Perlでのメモリ開放について - skozawa's blog
Perlで大規模な処理をしたときに、メモリに気を使わないといけないことがあって、メモリの開放について調べたときに、以下のページを見て、スコープ外れただけではメモリ開放されないことを知ったので、自分でも試してみた。 http://skitai.blog98.fc2.com/blog-entry-49.html メモリ使用量の確認には Devel::MemUsed を利用。昔はcpanにあったぽいけど、今はないようなので、https://github.com/jozef/devel-memused からcloneして使う use v5.14; use strict; use warnings; use lib glob "modules/*/lib"; use Devel::MemUsed; my $mem_used = Devel::MemUsed->new; $mem_used->rese
(ry - skozawa's blog
(ry という表現がなぜか気になったので、分析してみた (ryとは (イカリャクとは) [単語記事] - ニコニコ大百科とは (ryとは『以下略』を意味するネットスラングであ(ry 由来は、『（略）』とタイピングする際に、ローマ字で(ryaku)とする表記かｒ(ry つまりこの言葉は略の略で、「わざわざ全部言わなくても(ry」というメッセージが(ry 転じて「(ry」と(ry 使用する箇所としては、わざわざ言うまでもない･言いにくいこｔ(ry しかし、使いすぎるとめいわｋ(ry なので、用法容量を(ry個人的にはまったく使わない表現だけど、言語処理するにはちょっとやっかいな表現。言いにくいことを書くときに使うので、著者の心理を表していることが多くておもしろそう。 データ 特に使う予定もなく適当に収集していたツイートデータを利用。2014年1月～3月のツイートの中から (ry を含む9921
Comainuをリリースしました - skozawa's blog
中・長単位解析ツールComainuをリリースしました。 Comainu | 中・長単位解析ツール ダウンロードはsourceforgeからできます。 ソースファイルとモデルファイルをダウンロードしてください。 モデルファイルは解凍すると1Gくらいあるので注意してください。 中・長単位解析器 Comainu プロジェクト日本語トップページ - SourceForge.JP 長単位というのは、国語研が採用している言語の単位のことです。 国語研が構築した現代日本語書き言葉均衡コーパス（BCCWJ）では言語単位として語彙形態論研究に適した短単位と構文・意味研究に適した長単位を利用しています。 Comainuでは、このうち長単位の解析をします（短単位はMeCabとUniDibで解析します）。 長単位は短単位（単語）以上、文節以下の長さで大雑把には文節を自立語部分と付属語に分けたものが長単位となります
Solrでrsyncによるレプリケーション - skozawa's blog
solrでレプリケーションをする際にbandwidthの制限ができなそうだったので、rsyncを使ってレプリするようにした。 通常はsolr/conf/scriptconfig.xmlに以下のような設定があると、更新があったときにレプリケーションされる。 <requestHandler name="/replication" class="solr.ReplicationHandler" > <lst name="master"> <str name="replicateAfter">commit</str> <str name="replicateAfter">startup</str> <str name="confFiles">schema.xml,stopwords.txt</str> </lst> <lst name="slave"> <str name="masterUrl">
技術の見せ方について - skozawa's blog
入社してから初めて、3日間の開発合宿に参加した。 開発したものをどの程度書いていいか分からないのでとりあえず感じたことを書く。 今回の合宿で一番勉強になったのが「技術をどう見せる」か。 合宿では、普段業務ではあまり行っていないデータ分析や、自然言語処理やクラスタリングなどのちょっとした技術を使って開発をした。こうした技術を使って開発したとき、その結果をどう見せるか、技術が使われていることをどの程度見せるかは結構重要だと思う。 今回開発して感じたのは技術は見えてないくらいがいいなということ。あからさまに技術を押し出すと普通の人は引くと思う。UI的にはおもしろそうというのが伝われば十分で、その裏に実はこういう技術が使われているというのはエンジニアとか技術に興味のある人にだけ伝わればいいと感じた。初音ミクとかは音声合成という技術が使われているけど、初音ミクというキャラクターが前面にでていて、技術
Kyoto.pmに参加して、LTしました - skozawa's blog
Kyoto.pm 05 Tech Talk on Zusaar に参加しました。 nekokakさんのClutchの話や、songmuさんのTeng::Plugin::SearchJoinedの話など、色々聞けて面白かったです。 LTはABテストを少しやって感じたことがあったので、ABテストの有意差検定の話をした。 有意差測るときに95%は厳しすぎるかもしれないということと、Statistics::PointEstimationを使えば、簡単に有意差検定できるよという話です。 use v5.14; use strict; use warnings; use Statistics::PointEstimation; my $data = [ [300, 1000], [350, 1000] ]; my $significance = $ARGV[0] // 95; my $a_stats =
Kyoto.pmに参加しました - skozawa's blog
Kyoto.pm #4 ハッカソンに参加しました。 http://www.zusaar.com/event/582004 参加しましたが、別のタスクをやってたりもして、あんまり時間かけられなかったので、発表はしてません。 ハッカソンでは、形態素解析器や辞書が違うとどの程度結果が変わるかを知りたかったので、形態素解析の結果を比較するサービスを作ってました。 ただ、途中で似たサービスを見つけてしまったので、モチベーションがた落ちでした^^; IPA、NAIST、UniDic、JUMANの辞書実演比較（Mecab） 作ったのは、こんな感じ。とりあえず、MeCab + 複数辞書で作ってみました。上のサイトだとどの部分が違ってるのか分かりにくかったので、異なる部分をハイライトしました。もう少しブラッシュアップしたい フレームワークはMojoliciousを使いました。Mojolicious初めて使っ
株式会社はてなに入社しました - skozawa's blog
新人研修を終え、まだエンジニア研修の最中ですが、 週末で少し落ち着いたので、入社しましたブログを書いてみます。 なぜはてなに入ったかを簡単に書こうかと思います。 大学院で5年間過ごした自分にとって、就職活動で一番悩んだのは、 研究者かエンジニア のどちらを選択するかでした。 もともと応用に近い研究をしていたので、どちらにも興味がありました。 なので、研究者とエンジニアでは何が同じで、何が違うのだろうかとか色々考えました。 考えた結果としては、 類似点 人に役立つ、人が面白いと思う技術（サービス）を開発する 相違点 現在か未来か エンジニア：数ヵ月後あるいは目の前の課題に取り組み、それを解決する技術（サービス）を開発する。 研究者：5年、10年先の課題に取り組み、それを解決する技術（サービス）を開発する もちろん、挙げれば他にもたくさんありますが、自分の中で重要視して点だけ挙げてみました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kyoto.pm 町家ハッカソンに参加しました - skozawa's blog