サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ドラクエ3
nantekkotai.hatenablog.com
CoffeeScriptでClassを作った場合、そのクラスをグローバルから参照出来ないんじゃん思った。 例えば、 class Hoge constructor: (@param) -> @name = @param.name setName: (name) -> @name = name getName: -> @nameこのCoffeeScriptをコンパイルすると以下のようなJSファイルが出力される。 (function() { var Hoge; Hoge = (function() { function Hoge(param) { this.param = param; this.name = this.param.name; } Hoge.prototype.setName = function(name) { return this.name = name; }; Hoge.
PHPには配列内に指定のキーを持つ値があるかを確認出来る関数がある。それがarray_key_existsだ。結構便利なもので、受け取ったデータに本当にあるかないか、この関数でチェックすることは多い。 そんな便利なものに慣れてしまっていたので、JavaScriptでその手の関数がないということが解って、ヤバいかな!などと思っていたら先人というものはどこにでもいるもので。 http://kevin.vanzonneveld.net/techblog/article/javascript_equivalent_for_phps_array_key_exists/ function array_key_exists ( key, search ) { // http://kevin.vanzonneveld.net // + original by: Kevin van Zonneveld (h
写植がかつてすごく稼げる仕事だったけれど、デジタル化の波であっという間に仕事がなくなったという話を知って、実は今のソフトウェアエンジニアも同じようなものなのではないかという考えが浮かんだ。 写植はアメリカンドリームだったのか? - たけうちとおるのスクリプトノート 「写植の時代展」の小冊子を読むと高度経済成長期やバブルの頃は写植という職業も大きく伸び上がり、普通の会社員の年収ぐらいを1ヶ月で稼ぐ事ができたそうです。当時の話を聞くと写植屋さんで5年程修行した若者は「のれんわけ」してもらい、高価な写植機を師匠からもらったり、買ったりして独立して行ったそうです。仕事は山ほどありました。なにしろ景気がいいので雑誌もどんどん創刊されその中の文字は全て職人さんが打った物でした。いまからはとても考えられない時代。写植で家が建つ。そんな時代だったそうです。 特殊技能として稼げる仕事だった写植だが、この後D
発生する仕組みは、おそらくChromeのポップアップブロックと同じ。 簡易的に解決したいならば、HTML要素にonclickイベントを直接書くしかない。 <div onclick="window.open('http://www.google.com/', '_blank')">openなう</div> よその関数内でwindow.open呼ぶとブロックされる感じ。 それはさておき、新規ウィンドウを開く動作がiPhoneとAndroidで違う 当たり前だよね。ごめんね。 iPhoneの場合 target="_blank"なリンクをクリックすると、ウオーンってなって、パカって開く。 一回ウィンドウ一覧が開いて、新しくウィンドウが開かれますよ〜、というアニメーションを一通り見させられるので、「今開かれているページは新しいウィンドウなんだ」ということがわかる。 Androidの場合 新規ウィンド
Macが二台あるが、そこをうまく、かつ面白く同期したいなあと思い、無料のプロジェクト管理(らしい)サービス「Unfuddle」を使うことにしました。 http://unfuddle.com/ 昔もアカウントを取って使っていました。あの頃はまだ若かったのでSVNリポジトリのために借りていました。 そう、このこのサービス、無料で200MBものリポジトリが使えるのです。 しかもいつの間にか進化していて、今ではGitが使える。 さらに、無料アカウントではプロジェクトは1個だけだが、なぜかリポジトリの数は無制限になっている。 このサービス、いつか破綻するんではなかろうか、などと思ってしまうほど太っ腹です。 あえて制限があるとしたら、無料アカウントだと、プロジェクトメンバーが2人までということだろうか。 まあ友達の少ない僕には関係のない話です。UIも使いやすい。 ここで自分はMacを使っていたので、M
http://yamashita.dyndns.org/blog/google-app-engine-xml/ こちらのサイトを参考に自分のブログのフィードを解析しようと試みた、がなぜかうまくいかない。 そこでElementTreeについて検索して調べると、以下のサイトにこのようなことが書いてある。 http://python.matrix.jp/modules/ElementTree.html 「.//comment」であれば、子孫の全ての「comment」タグのエレメントを見つけてきます。 山下氏のサイトではこれが、「./status」になっていた。自分はこれをそのまま「./item」でブログのフィードを解析しようとして出来なかったみたいだ。 以下に実際に解析したソースコードを掲載する。 import wsgiref.handlers import xml.etree.ElementT
MOONGIFTで紹介されていたのが気になったので、ローカルのMacMini上で試しに動かしてみた。 http://www.moongift.jp/2009/05/sinatbbs/ まずRubyGemsをアップデート。 $ sudo gem update --system動かすのに必要なものをインストール。 $ sudo gem install sinatra sequel haml sqlite3-ruby準備は整ったので、githubからダウンロード。 http://github.com/yhara/sinatbbs/tree/magazine 適当な場所にディレクトリを設置、中にある start.rb を起動する。 $ ruby start.rbそしたら http://localhost:4567/ にアクセスする。終わり。 Rubyと言ったらRailsだったけれど、あれは自分で動
CodeIgniterは素晴らしい。これは間違いない。無駄な物がなく、規則も緩いからわざわざフレームワークを迂回するためのコードを書かなくていい。標準でバリデーションもページネーションもある。面倒なことはない。 それでも使用するフレームワークをcakePHPに戻した。何が不満だったのか、そしてなぜcakePHPに戻したのか。 理由は簡単。それはつまりCodeIgniterの長所でもあるのだが、規則が緩いことである。規則が緩いと自己流のコードが増える。そのコードの流れを覚えているうちはまだいい。しかし、一日のうち一時間か二時間程度しか書かないコード、時には数日も放置してしまう個人用のアプリ制作だと、その自己流のコードの流れを思い出すだけでも中々のコストが発生してしまうことに気付いた。 cakePHPはCodeIgniterに比べれば、パフォーマンスも悪いし、規則もしっかりしているから時には迂
「最短距離でゴールを目指そう」と考えるとき、そこに含まれている意味は「最速でのゴール」だと思う。最速で目的地に着くためには最短で進むのが一番、と考えるのは合理的なように思える。 でも違う。 最短は単に距離が短いだけだ。 最速では距離は長くなるかもしれないが「勢い」があり、速度を保てる。結果的に最短よりも早く着くことがある。 走るコースも違う。 最短コースは曲がりくねった峠道を地道に進む。 最速コースは迂回した高速道路である。 最短=最速と考えてしまうのは、進行する速度が常に一定だと考えてしまうからではないだろうか。 車の運転で考えてみよう。 山を直線的に進む道と山を迂回する高速道路、どちらが早く山を越えられるだろうか。山道は距離としては短いかもしれない。しかし高速道路と同じ速度では走れない。それなりの速さで走り続けるには、適したコースを走る必要がある。 最短と最速の同一視は危険である。何が
このページを最初にブックマークしてみませんか?
『nantekkotai achieves』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く