guideline.gem https://github.com/r7kamura/guideline 恐怖体験があって、震え上がり、少しでも綺麗なコードが書けるようなGemつくってる。複雑過ぎるメソッドや、使われていないメソッドが定義されていないかとか、長過ぎる行を書いてないかとか、簡単なチェックを自動化できる。こういうコードは綺麗ではないみたいなことがふわっと言われているよりは、綺麗ではないコードというのがコードで表現されている方が安心感があると思った。もしコーディングルールとして文書化したのでみんな守ろうみたいな感じにしても、コードを書くときに常にそれを覚えていなければ意味がないし、常にそういうことを気にしながら、ずっと緊張しながらコードを書かないといけない。そういう風に常に何かに気を配りながら作業するというのは、意識は高いけど、疲れるから極力やりたくないし、そもそも新しくその文化に

Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less

2016/11/03 @ PHPカンファレンス2016 2016/12/15 @ PHPカンファレンス2016再演イベントにて改訂 2017/06/10 @ PHPカンファレンス福岡2017にて改訂 2017/06/10 @ PHPカンファレンス福岡2017講演録画 https://www.…

言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。

弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数

↓これに関連する記事です ↑これは心境を表しています blog.sushi.money 最近自分の仕事がとにかく遅いのでなんとかしたい．いくつか問題意識はあって，ひとつひとつ地道に改善していくしかなさそうだけど，なかなか実践できてない． Slack見がち ついつい見がち 他人の分報を眺めると時間が飛ぶ 普段閉じていればこんなことにはならない Slackが悪いのではなくて，ツールを使えていない自分が悪い 綺麗に書こうとしがち 綺麗に書くと後でメンテは楽 綺麗に書くためには，ひらめくか時間をかける必要があり遅くなりがち プロジェクトの全容を理解できていないことがある このメソッド何しているんだ，とか，引数はどう渡せばいいのか，とかなりがち 理解していないと必然的にコードを読む時間が多くなる そもそも機能を知らないみたいな問題も発生しがち コードは常に増え続けているので，読むべきコードは過去のも

はじめに 以前こんな記事を投稿しました。ノンデザイナー・デザイン初心者向け、デザイン虎の巻 上記記事では、デザインという漠然とした問いに対して、キモとなりそうな点をツラツラと挙げています。その中でレイアウトを知るという項目があります。これはプログラミングにおいても役に立つ重要な知識ではないかと思いました。 そこでレイアウトという1デザインメソッドをベースに、ソースコードの整形について具体的に考えてみました。もし何かの参考になれば幸いです。 前提条件 ここでのデザインとは設計のような上流・大きなものではなく、コードの見た目に関すること、表面的で単純なものです 名前やコメントの整形もある意味デザインとしても考えられますが、ここではレイアウトのみを取り上げたいと思います サンプルコードはJavaScriptになります（考え方なので他言語でも応用できるかと思います） 目次 デザインのおさらい 良い

2015.06.03 スキル 社会人になったばかりの若いエンジニアの中には、一度この道に足を踏み入れたからには、自らの技術一本で身を立てていけたらという、強い思いを胸に秘めている人も少なくないのではないか。 そう考えて今回、Rubyの父として知られるまつもとゆきひろ氏に、あえて「これからの時代に技術だけで生き残るには？」という偏ったテーマで取材を依頼した。返ってきたメールの冒頭にあったのが、次の一文である。 「技術だけで生きるというのは幻想である」 まずはその真意を聞くところから、取材は始まった。 まつもとゆきひろさん(@yukihiro_matz) 1965年生まれ。筑波大学第三学群情報学類卒業。プログラミング言語Rubyの生みの親。株式会社ネットワーク応用通信研究所フェロー、一般財団法人Rubyアソシエーション理事長、Speeeをはじめとした複数社の技術顧問、Herokuチーフアーキテ

この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

前置き 元ネタは、結城浩氏著の「数学ガール 乱択アルゴリズム」。 新しい言語を覚えるとき、慣れるために「充足可能性問題（3-SAT）を解く乱択アルゴリズム」（p.353）を実装するという癖をつけていま1す。 ということで。前回の Egison版 に引き続き。勉強開始約1ヶ月の Julia ( http://julialang.org/ ) で実装してみました2。 開発環境・動作確認環境 Mac OSX 10.9.5 Julia 0.3.5 コード # Rw3sat.jl sample(a::Array) = a[rand(1:end)] immutable Literal index::Int not::Bool end literal(index, not) = Literal(index, not) # issatisfied(l::Literal, x::BitArray{1}) =

[DL輪読会]Learning Transferable Visual Models From Natural Language SupervisionDeep Learning JP

ある日のこと、後輩たちがこんなことを言いました。 「ゆゆ式のコマをランダムに並びかえたら無限にゆゆ式が楽しめるのでは？」 真面目に計算してみると、10の15乗くらいの組み合わせができることがわかりました。 この記事ゆゆ式アドベントカレンダー20日目は、そんな無限にゆゆ式をたのしむためのシステムを真面目に作ってみた話をします。 コマの切り出し 漫画のコマを並び替えるためには、コマがバラバラな画像として存在していなければなりません。 なので、まずは自炊で電子化された書籍をコマの線にそって切り出していく処理を自動化することにしました。 上の図がふつうの4コマの1ページですね。これの枠線を識別して、1ページから8枚のコマを取り出してくる方法を考えます。 ハフ変換で直線検出 OpenCVという画像処理のライブラリに直線を検出するツールがあったので、まずこれを試してみました。 が、結果はこのとおり。

Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc