golang で streem を実装した。 - Qiita
この記事は Go Advent Calendar 2014、16日目の記事です。 はじめに Matz さんが streem という、ストリーム指向言語の開発を始めるらしいです。 まだ文法の設計段階ではあるけど、それなのにかなりの量の pull-req がバンバンと来てて凄いなーと思いつつも「この pull-req 量だと僕には出番無いなー」と思ったので、README.md に書かれているサンプルだけを頼りに streem を golang で実装してみました。 先日はネタで streem のマネをして yacc 定義部分だけ公開していましたが、本日ネタが無い中にTLがヒートアップして焦りに焦って勢いで実装してみました。いやはや異様な追い込みを感じます。。。 まずは streem を知る streem は README.md に書かれている通り並列実行を行いつつストリームを処理する言語です。
いろんなプログラミング言語で1582年10月5日を扱ってみる| mwSoft
概要 1582年10月5日〜1582年10月14日までの10日間は、何らかの自然現象（ゴゴゴゴゴ）によって時間が消し去れてた期間として知られています。プログラミング言語を使ってこの日を取り扱おうとすると、いろんな結果が出力されます。 今日はそんな素敵な日付である1582年10月5日と戯れて、貴重な1日を無駄にしてみたいと思います。 Java とりあえずJavaから。バージョンは7。 // 1582/10/05をパース Date dt1 = new SimpleDateFormat("yyyy/MM/dd").parse("1582/10/05"); System.out.println(dt1); // 1582/10/04をパース Date dt2 = new SimpleDateFormat("yyyy/MM/dd").parse("1582/10/04"); System.out.p
ソースコード上の主語は誰か、という話 - mizchi's blog
ふとTwitterで投げたらリプライたくさんきた これ素朴な質問なんだけど、ソースコードで英語でコメント書くとき、守護はIなのかWeなのかコードそのもので受動態で書くのか、どっちなの— 性格は糞 (@mizchi) 2013, 9月 23 @mizchi 一行目は主語無し（命令形）、長い説明をつける場合は 1.言い訳がましいコメントは I を主語に 2. 誰かと合意済みの事柄は We を主語に 3. 仕様に沿う振る舞いに変更する場合は It should be ~ などコード自体が主語であるように、と書いてる— Kensuke Nagae (@kyanny) 2013, 9月 23 @mizchi "add …": このコードは…を足します、"added …" このコードは…で足されました、"adding …" このコードは…を足しています— 中村氏 (@r7kamura) 2013, 9
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
俺の考えるプログラマー35歳定年説 - komagataのブログ
おはようございます。高熱を出したまま35歳、アスキーコードで言えば#歳になりましたkomagataです。 間違えてて去年書くはずだったプログラマー35歳定年説について。（その来年がきたよ～、見てる〜？ ＞ 俺） パッピーバースデートゥーミーフロム俺 - komagata 「フィジカル、メンタルで衰えてくる」とか「マネジメントへの参加要求が強まり自然にプログラミングから遠ざかる」とか「求められる成果の総量が上昇するのでしかたなく」という面も確かにあると思います。 しかし、 「平均的なキャリアプランなんぞ知ったことか。こっちは大手町辺りに派遣されてスーツで一生デスマ案件でJavaを書き続ける覚悟は完了してるんだよ！」 という我々にとっては関係ありません。にも関わらず我々が長文を書いてしまうのはなぜでしょう？ それは「誰も見てなくても関係ない」「真理鉱山に篭って一生続けられる」はずのプログラミン
社内勉強会はヤメだ。自主的はいらん、全員技術発表だ！ - @ledsun blog
社内勉強会について僕にも思うところがある*1。 社内勉強会をやらない理由 - 勘と経験と読経 社内内弁慶を社外勉強会に参加させる方法: ソフトウェアさかば 最初に言っておくと弊社は20人くらいしか居ないし、受託開発と派遣が半々くらいのSIerだ。 id:kent4989 の会社とはだいぶ状況が違う。 社内勉強会はやらない 結論から言うと社内勉強会はやっていない。やらない理由は発表者のコストが高くてメリットが少ない。 勉強会のつらさ IT系の勉強会のノリだと テーマに対して興味のある人が少なく参加者が少ない 最新ネタは業務と離れすぎていて、継続する努力がハイコスト過ぎる 研修のつらさ 教育を重視して基礎的な内容をやると 基礎的な内容だと教える側が刺激が足りなくて飽きる 教える側が教えるほどは理解していないので、事前準備がハイコスト過ぎる そんなわけで社内勉強会をやるのはやめました*2。 技術
評判のいいiOSアプリ開発のTips ベスト20 - その後のその後
『iOSアプリ開発に役立つTips』という Facebook ページをやっておりまして、そこで評判が良かった投稿（※）を 20 個ほど紹介します。 （※） Facebook ページの insights にある「クチコミ度」で判断しました アプリ実行中にコードを修正してそのまま実行中のアプリに反映させる アプリ実行中にコードを修正してそのまま実行中のアプリに反映させることができるXcodeプラグイン。 実機でもシミュレータでも使用可能とのこと。実機での動作検証中に修正して再インストールは時間かかるので、超ありがたいかも。 Injection for Xcode 投稿：2013/2/4 「PCのwebブラウザからiPhoneのカメラロールにアクセスできるようにするアプリ」のしくみ アプリ側でURLを発行している画面キャプチャがあるので、アプリにHTTPサーバ機能をもたせて（古いけどCocoaH
Summary of Scrum Guide
Japanese version only Scrum Gathering Tokyo 2011 で開催した Scrum Boot Camp の資料 #sgt2011 #scrumdo #scrumbc
アジャイルの「顧客に価値を届ける」の嘘と本当 - mizchi log
酔った勢いでアジャイルについて思うところを書く。 顧客に価値を届けるのは誰か 顧客に届く価値 = 目に見える成果物、という評価は、フロントに近い人間しか評価されなくなる傾向を抱え込む。顧客に価値が届くまでには段階がある。複雑なものほどワークフローが長大になる。お互いの価値を見積もれるのは、小さいチームでお互いの職種について理解がある場合の理想であり、多くの場合理想は理想である。大きなチームほど、フロントに遠い人間は自分の価値を伝えるのが難しい。 難しいことを難しいということ エンジニアが自分の仕事について、エンジニア以外への責任説明を果たそうとすると努力は必要だが、必ずしもそれが伝わるとは限らない。 難しいことを難しいと言えないと、「それってすぐできるんでしょ？」という展開になりがちで、「任せてくれ！」と言えるのはかっこいいが、誰しもがスーパーエンジニアではない。そして見積もりに失敗する。
ゆーすけべー日記
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
凝ったコードは凝っているように見えない - 日々常々
新しい技術を使ったり凝ったコードを書くとメンテするのが大変。新しく入ってくる人でも分かるように書く必要がある。 この意見に対する上手い切り返しが出来るようになりたい。— Hidari。 (@Hidari0415) 2012年12月27日 "凝ったコード"……はどうだろう。 コードを書くことに凝るのはいい。でも、出来上がったコードが "凝っている" なんて言われるのはよくない。なぜなら "凝っている" と言われるコードは、おそらく "巧妙なコード" になっているから*1。そう言うのは得てして読みづらくて、凝りを解きほぐさないと理解しづらかったりする。そのようなコードは書くべきではない。コードの可読性から来る理解の容易さが全てじゃないが、他の条件がすべて同じ場合、読みやすいコードを書いた方が良いに決まっている*2。 コードのメンテナンスは書いた瞬間から始まっているし、その場しのぎは長生きするも
iPad miniで持ち歩けるコーディング環境を作る
iPad mini + Cellularを朝一番から並んで買いました！軽くてLTEでネットが使えるということで、外に持ち歩き端末としてはApple史上最高な端末です。 しかし、私は出かけるときには常にコードを書ける環境を持って歩きたいので、結局MacbookProかAirを持って出かけることになってしまいます。 最近、MBP15に代えたのでちょっと持ち歩きが厳しいなと思っていたので、この際iPad miniでコードを書く環境を構築することにしました。 まずはキーボード。前に買ってあったrapoo E-6300をBluetoothで接続してみます。一発でつながったし、サイズ感も良い感じです。 蓋になる形のキーボードも出ているようですが、とりあえずE-6300で問題なさげ。 次にメインとなるエディタです。iPadでソースコードを書くのに適していて、Dropboxに対応しているエディタといえば、
エデンの園でおきたこと - steps to phantasien
有給を駆使し一足早くクリスマス休暇に突入、ヒャッホイ Ingress やるぜーと 意気込んでいた矢先ノロウイルスにやられダウンした。かなしい。鎮まれ俺の胃袋・・・ そんな腹痛日和の気晴らしとして今日は Garbage Collection Advent Calendar に参加してみることにしました。 Advent Calendar 初体験につきよくわかってないけど勝手に参加していいんですよね？ GC というとジェネレーショナルだのパラレルコンカレントだのといった話が目立ちがちだけれど、 現実の問題というかブラウザを相手にするとそれ以外の細々とした面倒が目につく。 GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の１つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
goworker
Unix修正主義
数式を綺麗にプログラミングするコツ #spro2013
28歳からのプログラマー
コードの複雑さを上げずに「世界の複雑さ」と戦うために読んでおきたい良書5選【2012年のインプットlog-和田卓人】 - エンジニアtype
