プログラマーあるある
2 名も無き被検体774号+ :2013/05/03(金) 10:02:32.36 ID:gRysudru0 ＰＣの周りにスターウォーズのフィギュアを飾ってる人が多い。 3 ◆ossan//02w :2013/05/03(金) 13:57:36.84 ID:h01jv9j60 ソースコードは景色で見ると違和感を見つけやすい 6 ◆ossan//02w :2013/05/03(金) 20:31:03.36 ID:6dnkBP7c0 トイレやタバコの時に閃きはよくあるわ 8 名も無き被検体774号+ :2013/05/04(土) 13:25:25.55 ID:9xKuQIRO0 忙しくなると人柄が変わる 9 名も無き被検体774号+ :2013/05/04(土) 13:50:37.68 ID:BUXS7eIx0 居眠りが上手になっている 11 名も無き被検体774号+ :2
GPS受信機開発の参考資料 - OSQZSS
FPGAベースのGPS受信機開発に興味ある方のために，参考資料をまとめておきます． まずは，Namuru-NanoのベースとなっているUNSWのNamuru受信機のverilogソースコード． http://www.gmat.unsw.edu.au/namuru/ Namuruの相関器は，基本的にZarlink社のGP4020というベースバンドプロセッサのクローンになります． 通常，このようなデバイスの仕様については，メーカとNDAを結ばないと知ることができないのですが， GP4020については詳細なデザインマニュアルが公開されています． http://ulp.zarlink.com/zarlink/hs/82_GP4020.htm dm5280-design-manual-jan2002.pdfの第7章が，相関器に関する解説になります． 各レジスタの役割や信号処理の手順まで丁寧に説明され
「ピープルウェア」を読んだ - $shibayu36->blog;
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者:トム デマルコ；ティモシー リスター日経BPAmazon この本はソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。 最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。 早くヤレとせかされると 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。 またこの本の関連する内容に「
スタートアップで働くプログラマとして、非プログラマに対して気を付けなきゃいけないと感じていること - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 前回、非プログラマに対してプログラマに理解してほしいことというのを書いたら、なんかあとから伸びてきて、みんな思っていたことだったんだなーと思う反面、逆に一方通行に、プログラマだけが理解しろ！というのではなく、自分がプログラマとして働く上において、ちょっとだけ意識していることをあげておいたら、お互いにWin-Winかもね、と思う。そもそも、何かを要求するのに何も与えないというのも都合のいい話だろう。 もちろん、プログラマというのは一括りにできないし、前回の如く、当たり前にやっていることかもしれない。また「気を付けている」ということなので、気を付けている程度で本当はできていないかもしれない。 ただ、自分としては、非プログラマに対してこういうコミュニケーションが出来たら理想だなと思っている。そして、これはスタートアップの話である。すべての組織に適応できればベターだけど、そう簡単ではない
【速報】本日、株式会社ヌーラボを退職しました。【エンジニア急募！】 - slow living in the sky
会社に退職届を出しました。 私はこのブログに個人的なことを書いたことは１度もなかったのですが、この度、株式会社ヌーラボを辞めることになったので、ご報告致します。 喧嘩別れしたわけではなく、非常にお世話になったので、この場を借りて感謝の意を評します。 初めて入社した会社で、レベルが高くとても楽しかったので、その辺も書いておきますね。 辞めた理由 ヌーラボは、Backlog と Cacoo、そして TypeTalk を運営する福岡のベンチャー企業です。 とても暖かい社風で、みなさん笑顔で楽しく仕事をしているような会社です。 Javaを基板に開発を進め、非常に技術レベルが高く、JavaのアジャイルであるSeasar2などのコミュニティの一員でもあります。 個人的にこの業界が合わなかったのかも こんな暖かくて楽しい会社なのですが、やはり業務は一般的なIT企業と本質的なところは変わらず、重い責任がの
Eメールで作業内容を管理するのはやめましょう - GoTheDistance
BacklogとかサイボウズLiveとかをご存じないクライアント様が結構多くて、そのような方々にとってのコラボレーション・ツールはほぼ間違いなくEメールになります。まずその啓蒙から入って仕事をさせて戴くことが多くなりました。 お打ち合わせの場でAction決めて、その後はちょいちょいメールフォローでだましだましやってこれた時もあったのですが、やっぱこれダメだってことになったので、その話をしたいと思います。 Why Email Collaboration SUCKS そもそも、Eメールは双方向性があるようで無いツールです。Eメールでの各種進捗管理は、以下の点で非常に効率がよろしくありません。 １つのメールに複数の事項が含まれることがある 例えば、Xさんに対してAという事項の修正事項が記載されたメールに対して、Xさんが返信を行ったとします。その返信に対して別のBという事項のご相談があると、追い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
