jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない
仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか
コード補完もできる Go の REPL「gore」を作った - 詩と創作・思索のひろば
タイトルの通りです。Go は LL 的に使える、とはよく申しますが、そういう意識で使っていると REPL 的なことをしたいときに困りがちですよね。そこで作りました。gore。いい名前ですね。 motemen/gore · GitHub 以下のスクリーンキャストでだいたいの雰囲気をお察し下さい。 （スクリーンキャストは cho45/KeyCast を使って撮影しました） 特徴 gore の特徴は以下の通りです。 ラインエディタと履歴 複数行入力 パッケージのインポート、補完つき 式および文を実行可能 コード補完（nsf/gocode を利用） プリティプリント（k0kubun/pp か davecgh/go-spew がおすすめ） ドキュメントも引ける（godoc が必要） 以上のように、非常に便利なものになっております。むしろこの程度 REPL には当然あってほしい機能だとも言える。 イン
JitPack | Publish JVM and Android libraries
Add it in your root settings.gradle at the end of repositories: dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() maven { url 'https://jitpack.io' } } } Add it in your settings.gradle.kts at the end of repositories: dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { m
Goのdatabase/sql.Stmtのスケーラビリティを改善しました : DSAS開発者の部屋
先日、 Goに初めて私のパッチが取り込まれ 、コントリビュータに仲間入りしました。 このパッチは、 database/sql.Stmt をヘビーに使った時に性能がだいたい16コア以上のコア数にスケールしないという問題を解決するものです。 こういった問題をどうやって調査するのかと、Goにパッチが取り込まれるまでの手順を紹介します。 背景 私は TechEmpower の FrameworkBenchmarks という、いろんな言語/フレームワークで同一のアプリを作ってベンチマークするというプロジェクトで、主にPython関連のメンテナをしています。 Goにも興味があるので、Ginというフレームワークを追加したりコードレビューに参加したりしています。 2014-05-01 に行われた前回のベンチマーク Round 9 では、 PEAK Hosting が実行環境に加わりました。この環境は、デュ
第1回 DSLとは？ | gihyo.jp
第1回目は、DSLの基本的な概念について説明します。 DSL概要 DSL（Domain Specific Language）は、ドメイン固有言語と訳されてます。DSLは、Java、C#などの汎用言語とは違い、ある特定の種類の問題に特化したコンピュータ言語です。 今回の連載では、DSLの世界を解き明かします。そして、実際にDSLをつくることで、よりDSLの理解を深め、「用法・用量を守って使える」ようになるのが、今回のゴールです。 DSLの必要性 なぜ、DSLを学ぶ必要があるのでしょうか。 Ruby on Railsの登場以降、メタプログラミングという言葉を良く聞くようになりました。メタプログラミングというと、マクロ、コードの自動生成、テンプレートを上げることができます。 DSLは、メタプログラミングで使われます。メタプログラミングは、一般的なプログラムとはまったく違った方法をとっているので
Big Sky :: golang のリファクタリングには gofmt ではなく、gorename を使おう。
今まで golang で変数名や関数名のリネームには gofmt の -r オプションを使ってきましたが、これからは gorename を使いましょう。 文法を解析して正しくリネームしてくれるので、gofmt で起き得た誤爆も心配ありません。インストールは以下の様に実行します。 $ go get golang.org/x/tools/cmd/gorename 使用方法は以下の通り。 gorename: precise type-safe renaming of identifiers in Go source code. Usage: gorename (-from <spec> | -offset <file>:#<byte-offset>) -to <name> [-force] You must specify the object (named entity) to rename
PHP 5.4.4から==の挙動が一段と難しくなりました - hnwの日記
PHPの==は両辺を適当に型キャストしてから比較するような演算子です。この型キャストの規則は難解すぎる上にドキュメントも不十分なため、PHPプログラマでも完璧に理解している人はほとんど居ないくらいの印象です。バグの原因になりかねないため、なるべく==を使わないようにしているPHPプログラマも多いはずです。 ところで、この==演算子の挙動がPHP 5.4.4から変更されていることはあまり知られていません。本稿ではこの内容を紹介します。 Bug #54547 の騒動 まずはこの仕様変更の経緯を紹介します。 2年ほど昔、Hacker Newsで2^63付近の整数に対応する文字列をPHPで比較したときの挙動がおかしいというスレッドが盛り上がったことがありました。具体的には、PHPでは「'9223372036854775807' == '9223372036854775808'」がtrueになるとい
nuwk!とvue.jsでらくらくデスクトップtodoアプリ - Qiita
javascriptでデスクトップアプリが作れるnode-webkitのビルドツールnuwk!と、超軽量MVVMフレームワークのvue.jsを使ってデモアプリを作ってみました airtoxin/MiniTodo 見た目… 準備 node.jsをインストールしてnpmが使えるようにする node-webkitとnuwk!をインストール vue.jsのmin.jsをダウンロード nuwk!を開いて新規プロジェクトを作成 ここまででnuwk!がHello Worldのテンプレートを作ってくれるので、満足するまでそれらをいじってからBuild projectすればBuildディレクトリにappとしてアプリケーションが作られます。 テンプレート部分 Appディレクトリ中のindex.htmlを編集します。 <link rel="stylesheet" type="text/css" href="./
Unix Philosophy と Node.jsのモジュールの作り方 - from scratch
The Art of UNIX Programming 作者: Eric S.Raymond,長尾高弘出版社/メーカー: アスキー発売日: 2007/06/19メディア: 大型本購入: 4人 クリック: 91回この商品を含むブログ (62件) を見る TL;DR Unix Philosophyにおいては、「一つのことをうまくやり、協調する仕組みを持つ」という事が大事 Node.jsのモジュールにおいても同じで、「一つのことをうまくやる、Stream APIで協調する」と良い 「一つのことをうまくやる」にはどうするのが良いのか、ということで substack のモジュール実装例 Simple と Easyの違い ちょっと今回長くて文字が多いので、最初と最後にまとめを用意しました。時間がない方はこれを読むだけでもいいかと。 Unix Philosophy さてさて、Unix Philosoph
git-gutter.el - naoyaのはてなダイアリー
寝れないので変な時間にブログを書いたりする。 時折思い立ったように Emacs Lisp を見直して色々導入を試みたりするも、結局割り当てたキーバインドを忘れてたりして定着しない、というものは多い。そんな中でもここ1, 2ヶ月くらいで定着したのが git-gutter.el。 このように緑のプラス記号なんかが出て git で管理しているファイルを編集した場合の差分がどこかが一目でわかる。 多くの elisp がそうなんだけど、導入する前までは便利そうだけどそこまで必要かな? と思いつつ入れてみたらもう手放せなくなった、そういう類です。ぼーっとしながらコード書いてる時でも、あそことあそことあそこを編集したんだなってのが git diff とかしなくても分かる。 これを入れるとちょっと動きがモッサリするみたいな話もあるけど、作者の id:syohex さんが鋭意改善中 (http://d.ha
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
情報工学でコンパイラを学ぶべきか | Scene Research Station
高専の友達と呑んでいた。 なんでそういった話になったか覚えていないが、情報工学畑の僕が 「大学の実験ページを見たらコンパイラ演習が無くなっていて驚いた。情報工学でコンパイラも作ったことないってどうなのよ？アカンでしょ」 と言ったところ、電気電子畑の友が 「そんなもの『電気科で８石スーパーヘテロダインラジオも作らないで卒業するのは許せん！』と言っている老害と同じ。やるべきことは時代で変わる。会社でも特定の技術に長けて成功した人ほど、視野が狭くなって老害化してほんと困る云々」 というようなことを言った。 ちょっと話は逸れるけど、家電メーカーでもあるよね。一度テレビで成功しちゃったが故に、赤字になってもテレビをいつまでも家電の王様と信じて作り続けちゃう、みたいな。バカは死ななきゃ治らない、って言うけど赤字事業でもそれに従事するエンジニアは超一級で、そもそもかつてテレビは最先端の花形事業であって、
Vim で C# を書くなら OmniSharp で決まり！ - 永遠に未完成
Vim Advent Calendar 2012 の 173 日目の記事です。 今回は C# を書くのに便利な OmniSharp と言うツールを紹介します。これさえあれば、エディタとしての Visual Studio はもう必要ありません！ 経緯 (興味ない人はここは飛ばしてインストールのところから読むと良いです) 先日、OmniSharp なるものの存在を教えてもらいました。 @thinca これってでどうなんでしょう URL 2013-05-09 23:47:26 via YoruFukurou to @thinca @mizchi お、面白そうですね！私は知らなかったです。明日あたり見てみますー。ありがとうございます。 2013-05-09 23:51:36 via tweetvim to @mizchi と言うわけで調査してみることにしました。 様々な罠にかかりつつ、ソースコード
ssh上でマウススクロールも使える大規模PHP開発向けvim+tmux環境の構築 - sifue's blog
全体で数百万行、1ファイル1万行超のPHPファイルも一秒以内で開き、開発していくことのできる大規模開発向けのvim+tmux環境を紹介しようと思います。この設定この環境で半年ぐらい安定して利用できています。(無論そんな1万行あるファイルや数千行で複雑性循環度500超のメソッド作るなよという話もあるんですが、すでに存在する魔獣とは向き合わなければならないのです...) なので数百万行レベルの大規模開発となると重すぎて使えない設定やプラグインもあります。そのようなものはきちんと外してあります(PHPの関数折りたたみ機能、デフォルトのPHPシンタクスハイライト、neocomplcache.vim、ツリーの構成に時間のかかるproject.vimなど)。 基本的にはターミナルエミュレーターとして、macならばiTerm2、windowsならばTeraTermまたはPuttyを利用することを想定して
PHPを愛する試み - maeharinの日記
僕はRubyが好きだ。プライベートではRubyばっかり使っている。でも、仕事ではPHPを使わなければならない。これまでPHPは書きにくいーと思い込んでいてあまり好きではなかったのだけど、仕事で使う以上PHPを好きになった方がきっと幸せになれる。何かを好きになるにはどうすればよいか。そう、相手のことを知る努力をすればいいんだ！ということで、PHPについて知る努力をしてみた。 PHP The Right Wayを読む http://ja.phptherightway.com/ ☆PHPへの愛が100上がった☆ これは... PHP好きになれるかも！ 普段Rubyで書いてるコードをPHPで書いてみる 折角なので自分が普段Rubyを使っていて便利だなーと感じていることをPHPではどう書くのか（厳密では無いにしても大体同じ内容はどう書くか）試してみた。Rubyは1.9.2、PHPは5.3.10。 多
全てのwebエンジニアがPythonを勉強するべき2013年到来
あけおめ！今年は巳年。へび。へびと言えばPython。そう今年は全てのwebエンジニアがPythonを勉強する最高の環境が整った年なのです。 既にPerlやRubyを習得してるけど、それに加えてPython必要？必要です！必要だと思います。もはやPythonはwebエンジニアにとって必修言語となりつつあると思います。Linuxの多くの箇所でシステム言語として用いられ、可読性の高さから多くの技術系書籍のサンプルコードとして用いられ、科学技術系分野におけるエコシステムの充実っぷりはますます磨きがかかっており、様々なライブラリがどんどん出てくる現状を「Pythonわからないから自分には関係無い」と遠巻きに眺めるのはもったいないです。 習得するのにどのくらい時間かかるの？あなたが既に他の言語に慣れ親しんでいるなら、特にRubyなどに精通していれば「1週間」で基本的な読み書きは出来るようになるでしょ
Vimのsnippetについてあまり知らなかったので設定してみたら便利過ぎてつらい - 僕の車輪の再発明
今までこれを使いこなせてなかったなんて、今までの人生をなかったことにしたくてつらい・・・ vimでneocomplecacheを使用していて、スニペットの候補が来た時にCtrl-kと打つとスニペットが展開されることは知っていましたが、いまいち意識して使えていない状態が続いていました。 とりあえずスニペット使ってみる 追記 一応下のようにプラグインが入っている前提です。 NeoBundle 'Shougo/neocomplcache' NeoBundle 'Shougo/neosnippet' 追記終わり 追記 2013/01/19 現時点でのおすすめ設定も書いているのでそちらも参照 今しているneocomplcache + neosnippetの設定の自分的おすすめ - 僕の車輪の再発明 追記終わり 例えば「PerlとVim」で言うと、この記事がかなりの良記事になっていて、そこでもスニペッ
プログラミングのルール
自分のルールを twitter に書いてみました。1時間半ぐらいやってたらしい。 ＊ ＊ ＊ 変数名やクラス名に省略した単語でなく正しいスペルのものを使う。 他人のインデントはいじらないが、間違ってるのはなおす。同じインデントシステムを使う。勝手に発明しない。ちなみに、K&R 大域変数は使わない。Singleton も使わない。インスタンス変数経由でパラメータを渡さない。必要な場合のみに使う。 コメントは関数/メソッドの役割に対しておこなう。bug fix comment には例を含める。 測定を伴わない最適化は無意味で間違っている。 xUnit を使う。 修正前のコードを残すようなことはせず、版管理にまかせる。 fprint() ; exit() ; のようなエラー処理をせず、エラー処理ルーチンを呼ぶ。 malloc を裸で使わない。 use case 図から書き始める。 if else
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mohayonao/gretro: :art: JavaScript graphic library for retro CG