タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

programmingとProgrammingとdevelopmentに関するkmachuのブックマーク (5)

  • GitHub Flow (Japanese translation)

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub Flow (Japanese translation)
    kmachu
    kmachu 2013/01/16
    masterをmergeするのはいいアイデア。 僕は(1)ローカルでトピックブランチを作成し、まめにコミット。(2)形になったらrebase masterでHEADに追従、rebase -iでコミットを整理。(3)GitHubにpushしてpull request。公開してからはrebaseしない。
  • ちょっとした GUI アプリケーションをつくるのに MacRuby はよい選択肢となりうる - tokuhirom's blog

    ちょっとした GUI アプリケーションをつくるのに MacRuby はよい選択肢となりうる ちょっとした GUI アプリをつくるのに MacRuby をつかってみた。結論からいうと MacRuby はよくできているなあ、という印象をえた。 昔、RubyCocoa をさわってみたことはあったのだけど RubyCocoa は 「なんか正直 Objective-C の方がむしろ楽な気がする。。」 という感じだった。なにしろめんどくさいという印象しかのこらなかったのである。 一方、 MacRuby はいいな。 Syntax をカスタマイズすることにより無理矢理実現している変態的な感じもよい。実用的。 ちょっとした自分用ツールをかくときに今までは web application としてかいていたのだけど、MacRuby の方が楽だな、そんな気分になったのであった。 (というか、最初 Web Appl

    kmachu
    kmachu 2013/01/08
    MacRuby気になる。
  • Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ - プログラマの思索

    Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 #以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記

    Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ - プログラマの思索
    kmachu
    kmachu 2008/02/25
    「リダイレクトとは、フォワードを2回以上実行すること」←HTTPの視点からだと全然違う。「何故、オブジェクトでセッションに保存できない?」←できないんだっけ?
  • 「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena

    なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。

    「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
    kmachu
    kmachu 2007/09/11
    「それは「再発明」ではなく「再実装」であって、とても大切な行為です」←激しく同意
  • プログラミング環境への妄想を書きなぐる - sshi.Continual

    http://d.hatena.ne.jp/textfile/20070612/manを見た。コードを書くのは好きだが、マニュアルやドキュメントを書くのはめんどくさい。いいきっかけなので、今かかえてる妄想を吐きだしておく。 実行可能なコードでありながら、 記述の抽象度が高く、 UML程度(あんま詳しくないけど)に把握可能な粒度の記述も可能な言語仕様であって、 そこにひとことふたことコメントを記述すれば、 そのままマニュアルとしても通用する なんていう言語は実現可能だろうか? まず、(今よくあるような)関数定義を羅列するスタイルだけでは、ちょっとのコメントだけでマニュアルとして通用するものにはならないだろう。少くとも、ぱっと見て期待する外部仕様がわかるようなもんじゃないといけない。例えばテストも同時に記述しないといけない、とか?あ、事前条件、事後条件とかを記述する言語もあったな。Eiffel

    プログラミング環境への妄想を書きなぐる - sshi.Continual
    kmachu
    kmachu 2007/06/12
    ソースコードは仕様書の代替にはなるけど、マニュアル (How to use it) の代替にはならない気がしてる。だとしたらテストスイートがマニュアルかなぁ?
  • 1