オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
1億調達した16歳天才プログラマーは日本復活をかけて東京で戦う
カード決済アプリ｢ONE PAY｣のワンファイナンシャルというベンチャー企業が、1億円を調達したとのニュースが今秋、世を駆け巡った。注目の理由は16歳の経営者。中学生時代から5つのベンチャーを経験してきた、現役高校生だ。国際的なプログラミングコンテストやビジネスコンテストで数々の賞をとり｢天才プログラマー｣の名をほしいままにしている。21世紀生まれの時代の寵児は、いかに育まれたのか。 大手町ビルの一角にある、フィンテックの有望スタートアップ企業が集積するFINOLABを夕暮れ時に訪ねると、黒いTシャツに黒いジーンズという軽装の若い男性が、ひょっこり現れた。ワンファイナンシャルCEO、山内奏人(そうと）さん（16）だ。 放課後には、毎日ここで仕事をしているという。 ｢僕らは早すぎた｣ ｢ブロックチェーンは絶対に来る、と思っていたのですが、僕らは早すぎました。波来ないな、とプロダクトを撤退した
『テスト駆動開発』を読んで - まめめも
テスト駆動開発posted with amazlet at 17.10.12Kent Beck オーム社 売り上げランキング: 563 Amazon.co.jpで詳細を見る オーム社さまから電子書籍を贈本いただきました。ありがとうございます。 本書はテスト駆動開発（TDD）の原典で、たいへん有名な本です。が、自分は食わず嫌いで読んだことがありませんでした。 というか、TDD 自体もちゃんと理解したことがありませんでした。なんだろう、なんか怖かった。 そんな自分が今回この本をいまさら読んでみたら、なるほどこれは確かにいい本でした。なんというか、語りたくなる感じ。ということでご紹介。 紹介 テストとプログラムを交互に書いていく開発方法 TDD を、例題を用いて実演していく本です。 TDD というと「プログラムより先にテストを書く」というところだけ強調されますが、正直それではよくわからないのでし
伝説のプログラマーが説く「時間通りに絶対終わらせる」仕事の進め方 - リクナビNEXTジャーナル
長時間労働が大きな社会問題となっている昨今。「ノー残業デー」や「プレミアムフライデー」など、長時間労働を是正するような取り組みが一部の企業で行われています。けれど「そうは言っても、なかなか早く帰れない」「そもそも仕事が終わらない」と悩んでいるビジネスパーソンも多いのではないでしょうか。 Windows95の生みの親のひとりであり、「右クリック」「ドラッグ&ドロップ」を現在のような形に設計したというソフトウェアエンジニアの中島聡さんは、著書『なぜ、あなたの仕事は終わらないのか』（文響社）が10万部を超えるベストセラーとなっています。著書では「ロケットスタート時間術」を公開している中島さんに、「どんな要因があっても絶対に早く仕事を終わらせる」仕事の進め方を伺います。 中島聡さん UIEvolution Founder / neu.Pen CEO 1960年、北海道生まれ。高校在学中からアスキー
今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に
GWの進捗としてRPG作った / redux-saga でメインループ処理、JSONSchemaからのコード生成 - mizchi's blog
作った。GWの間、コンビニと近所のカフェ以外に外出してないし、ゲームもしてない。 https://mizchi-sandbox.github.io/rpg-prototype/ で触れる。デザインはしょぼい。Chrome以外で動いてる気がしない。 コードはここ https://github.com/mizchi-sandbox/rpg-prototype 仮素材はウディタに付いてくるサンプル素材をお借りした。 WOLF RPGエディター公式サイト 【RPG作成フリーソフト】 仕様 Spaceでポーズ＆リスタート クリックでスキルの使用 一度スキルを使ったらクールダウンがある Player1 だけ操作できる あとはなんか察してほしい。 何故作ったか 前々から、ゲーム、とくにRPGを作りたいと思ってたのだけど、メインループがすんなり綺麗にかけたためしがない。趣味プロジェクトは技術的に辛いとやる
Hayato.io
Hayato.io This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Health Insurance find a tutor Top 10 Luxury Cars High Speed Internet fashion trends Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Cookie settings|Do Not Sell or Share My Personal Information
スタープログラマの幻影 - megamouthの葬列
最近久々に「スタープログラマ」という言葉を聞いた。 そういえば、私の中にもかつてそういう存在がいたなあ、と思い出した。 あえて定義することもないが、スタープログラマとは、先進的なOSSプロダクツを実装し、ブログなどでプログラミングを堂々と論じ、できれば単著の一つも書いているような人たちといったところである。 話の都合上、具体的な名前を出すが、高林哲氏、higepon氏、新山祐介氏などが、私にとってのスタープログラマであったし、少し時代を戻すとεπιστημη氏であるとか、賛否両論だとは思うが、やねうらお氏などの名前が挙げられるかもしれない。 スタープログラマというのは、駆け出しのプログラマやプログラム学習者にとっての目標であり、先輩であり、嫉妬の対象でもある。 彼らの言葉は絶対で、疑う余地もないことであり、私はそのプログラミングに対する思想を無条件に受け入れたし、彼らが使っているエディタや
単一責任の原則(SRP)についての見解と方法論 - FLINTERS Engineer's Blog
こんにちは@kimutyamです。 今週末はいよいよScalaMatsuri2017ですね。 弊社は、今年も将軍スポンサーとして参加させていただきます。 そして今年も同人誌を配布させていただきます。 同人誌については去年配布した話を杉谷がブログで紹介しております。 labs.septeni.co.jp 今年の同人誌目次は以下となります。 ScalaでAndroidアプリ開発 単一責任の原則(SRP)についての見解と方法論 末尾再帰の呼び出し最適化の有無によるScalaコンパイラの挙動について Akka HTTP で LINE bot を作ってみました 新卒scalaエンジニアが書くISUCONの歩き方 去年に比べて記事数は少なめですが、内容は濃くなっております。 ちなみに私は弊社の今泉と一緒に『単一責任の原則(SRP)についての見解と方法論』を執筆しました。 (Scala関係ないw) 代わ
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
Big Sky :: Matz の「言語のしくみ」を読んだ。
Twitter で「言語のしくみ」読みたいなって呟いたら Matz 本人から「献本しましょうか」とメンション頂いて即答でお願いしました。ありがとうございます。 ひさびさ紙の本を通勤電車の中で立ちながら読んだので手がだるくなりました。なんだか懐かしい感じがしました。 さてこの本ですが、一言で言うとこんな本です。 Ruby のパパこと Matz が雑誌の連載に追われながら試行錯誤して作ったプログラミング言語「Streem」を解説する本 聞こえが悪かったらすみません。言いたいのはこの「試行錯誤」がとても良いエッセンスになっている点なのです。実際にはその連載記事をまとめた物に対して、この当時はこの様に考えていたが後になってみると実は良く無かったといった振り返り「タイムマシンコラム」で構成されています。 この連載が1つの本に纏められた事でプログラミング言語設計者の葛藤が非常に良く表されているな、そう
404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス
2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する：ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来る
自分は頭がいいから未経験でもすぐ即戦力になれる - 負け犬プログラマーの歩み
という思いあがりを持つエンジニアは少なくない。というか、現状の俺が今この状態に陥っている。 もちろん、この思考回路自体は決して間違いではない。プログラミングにおけるセンスや問題解決能力、情報収集力などは凡そ普遍的なものだから、言語やフレームワークみたいな些細なもの、時にはパラダイムの違いですらも、優秀な人間であればごく短期間で乗り越えて、その能力を遺憾なく発揮できるはずなのだ。 その辺りを理解している企業も多く、少しマイナーな言語や環境での募集の場合、たとえ未経験でも意欲と能力を買って採用する事も多い。というかむしろそれが普通なんだろう。その辺りの融通が効かない駄目な会社は、そもそも「最新の技術」なんて導入せず、既に枯れ始めて実績と経験者のあるものに固執するからだ。 ただ、問題なのは、たまに有能ではないのに自分の能力を過信して「俺は優秀なんだから何でもできる。さあ誘え」と完全に受け身モード
明日は誕生日なので本当の乞食というものをお見せしますよ - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 今年も生き伸びてしまった。 誕生日 in 山谷 とうとう33歳となった。33歳といったところで特別に何かが変わるわけではない。変ったことと言えば、山谷のドヤ街でゴロゴロし、隙間から這い出る虫(具体的な名前は付せる)の姿を見るにつけて、侘しい気持ちになったりするくらいのものである。そんな暮しとはいえ、パソコンさえあれば、プログラミングができるので、それで時間を潰し、その知見というものをブログに書くという日常を送っている。 時折、酒で酔っぱらった老人の唸り声が、薄い壁越しに聞こえてはくるが、文明の力であるところの耳栓があれば解決する。耳栓は下のものを使っている。しかし、半日ほどつけているため、耳の垢が貯まるのが唯一の弱点である。 MOLDEX 使い捨て耳栓 コード無し 6620 Goin'Green 10ペアパック 出版社/メーカー: MOLDEX(モルデックス)メディア: ヘルス
「60%の人間はプログラミングの素質がない」という論文は撤回されていた | catch.jp blog
知らなんだ。 広くプログラミング教育を実施しようというとき、「60%の人間はプログラミングの素質がない」と批評されることがあります。けれども、そもそも学校のテスト等で難易度が高い場合には、正規分布にならず、ふたこぶラクダのように頂点が2つになることがあるそうです。だから、プログラミングの素質がないのではなく、プログラミング教育へのモチベーション設定に失敗していたり、チャレンジングな教育目標が設定されているのではないかな。つまり、素質の問題ではなく、環境の問題なんだ。だとしたら、環境が改善されたら、ふたこぶラクダは解消されて正規分布に近づく。そして、平均点は上がるはず（ふたこぶの上位層はさほど変化しない）。 ということを考えて、いろいろ調べていたら、はなはだ旧聞なんだけど、論文が撤回されていたことを知りました。ぐぐっても上位に出てこないので、ここに書く。 元ネタは、これ。 The camel
まだたとえ話で消耗してるの? - K.Maebashi's はてなブログ
常に話題には乗り遅れる私ですが、ちょっと前、「変数を箱にたとえる」ことについて議論がありました。 プログラミングの変数を教えるときの「箱の説明」の是非について。 - Togetter 実のところこの話題は昔から何度も出てきた話で、「何周目だ」という話ではあります。私自身、「センス・オブ・プログラミング！」に書いたことがあります。 変数は「箱」か？ - the code to rock そして、上記の「the code to rock」の文章にもありますが、「箱モデル」の代わりとしてよく提唱されるのが「名札モデル」です。 こういうことは文章で書いてもわかりにくいので、それぞれ、絵にしてみましょうか。 箱モデル ■「a = 5;」という代入 「aという名前が付いた箱に、5という値を格納する」プログラミング言語の入門書によく出てくる説明ですね。 ■それに続いて、「b = a;」という代入 ここで
PythonからRubyに移行した人間の印象 - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 安物のねぎとろは、納豆と良くあう。 前提 はじめてのにき(2016-06-16) より。 このエントリの立ち位置について 元々はPythonを勉強していたのだけれども、仕事の関係上、Rubyを主軸にすることにした人間のエントリです。ちなみに、PythonとRubyの立ち位置には詳しくなく、主観を元に構成されているので、客観的な部分に関しては弱いことをお断りしておく。また、現時点での知識が2.7になっているので、3.5では多少違う点があるかもしれない。 なぜならPythonのほうが「わかりやすかった」から まず最初に、Pythonのほうが機械科学系の人に支持されやすい傾向としてあるのは、Pythonのライブラリ、例えばNumpyであったり、Scipy、または各種機械学習系のライブラリなどの影響が大きいのは間違いない。最近の機械学習ブームのせいなのか、Pythonも「エモい人(エモ
ハッカソンというイベントの目的とは何だったのか
おそらく僕がハッカソンを主催しだしたのは、2007年頃です。その時は、ハッカソンという言葉自体がまだほとんど知られていなくて、本当に珍しいことを始めたって感じだったのを記憶してます。そしてそれから8年以上が経過して、ハッカソンという言葉は広く認知されたのと同時に、その言葉が指すイベントがどのようなものなのかが「人によって認識が違う」状況となってしまいました。もちろん、好きに定義して良いことなんだけど、そもそも僕がハッカソンをデベロッパーコミュニティとやり始めたときにどんな認識でいたのか、今一度ここで再確認しておきたいな、と。 下記の内容は、ここで当時一緒にハッカソンを主催していた方々との会話から、僕が個人的に改めて当時の認識を言葉にしてみた文章です。 ハッカソンの目的 まず、ハッカソンの本来の目的がなんだったのか、ですが、これは以下でした。 普段の仕事では作らない/作れない何かを「試しで」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
