OSSコミッター最大の権利は「要望を無視する」こと - komagataのブログ
ボランティア開発者が「反乱」。もっとオープンソースに還元されるべき？（山口健太） - 個人 - Yahoo!ニュース これいろんな意見がありますよね。オープンソース・オープンソースコミュニティ大好きなので開発者・ユーザーにとって良い方向に進むといいなと思います。 それとは別に、オープンソース開発者の義務について思うこと。 OSSに好き勝手に要望を出すことは良いと思う。 「だったら自分でやれよ」って言っちゃうとフィードバックが無くなっちゃうので。 それと同時にOSSコミッターが持つ最大の権利が、 「要望を無視すること」 かな〜と思いました。（要望を「反論する」「却下する」ではなく「無視する」） 「好き勝手に要望を出すのはOK」ただしコミッタは「スルーする権利」を持つ。 好き勝手な要望に全部向き合わないといけないのではコミッターの体が持たないんじゃないかな〜と思います。 この「スルーする」って
SES企業はやめた方がいいですか？ - komagataのブログ
プログラミングスクールのフィヨルドブートキャンプを運営していて、就職に関するアドバイスを求められることも多いです。SESについてはよく訊かれるのでここにまとめて回答しておきます。 SESとは SES(System Engineering Service)とはソフトウェア開発・運用・保守における委託契約の一種です。特定の業務に対してエンジニアを派遣し、エンジニアリングの能力を時間で提供します。 他に一般的な契約として請負契約があります。（特定派遣については2018年に廃止されました） この二つは主に報酬の対象が違います。 SES：労働時間に対して報酬を支払う。 請負：成果物に対して報酬を支払う。 SESはその時間働いていれば必ずお金がもらえますが、請負は成果物（システム）ができなかったら報酬が貰えません。 請負が成果物によって報酬が出るか決まるということは、「成果物とは何か？」ということを事
Railsエンジニアとして就職できるレベルとは - komagataのブログ
仕事でフィヨルドブートキャンプというRailsエンジニアになるためのスクールをやっています。 FJORD BOOT CAMP（フィヨルドブートキャンプ） 「どのレベルになったら就職できるの？」 という点がイメージできないと、就職したい人にとってわかりづらいなと思ったので明確にしておきたい。 戦力として計算できるRailsエンジニアとは 僕の考える、Railsエンジニアとして就職できる最低レベルは、 「少しでもプラスの戦力として計算できる」 というものです。 「Issueを一人でこなせる」 といっても良いかもしれません。 「は？みんな10の戦力持ってるところに1とかじゃ困るんだけど？」 と思うかもしれませんが、Railsプロジェクトにとってほとんどの人類は1の戦力も無くて、マイナスです。 Railsチュートリアルを終わったばっかりで実務レベルの開発したことないぐらいの人もマイナス戦力です。
"リニューアル"っていうな - komagataのブログ
結論 リニューアルはマーケティング用語。Webサービス開発チームにとっては思考停止やストーリーの粒度アップをもたらす悪魔の言葉なので使わないようにしよう。 すぐリニューアルっていう問題 Webサービス開発においてサイト改善の粒度がリニューアルという名前になってたら要注意。 その場合、責任者が 「よくわからないけど、うちのサービスイマイチだからおれのかんがえるさいきょうの機能・UIに刷新しよう」 と考えていて、 自分のサービスにとって良いとは何なのか？ 何が問題点・ボトルネックなのか？ 何を改善するのか？ その仮説で本当に改善するのか？ そもそも仮説はあるのか？ 優先順位は？ などという地味な検討を避けてリニューアルという銀の弾丸を求めても、かさむ工数、ユーザー離れ、要らない機能などがサイトにもたらされるだけなのでヤメよう。対外的なマーケティング用語としてのリニューアルをWebサービス開発に
rnicrosoftがwindowsのソースコードをgithubで公開 - komagataのブログ
starseekerのフィード見てて、 ・・・えっ？ ・・・え？・・・・え！？ ・・・・・・・・・・・・・・・・。
レガシーPHPプロジェクトあるある - komagataのブログ
プロジェクト名に愛が無い そしてリポジトリ名がncrm（多分New CRMの略）。だったら更に新しいの出たら何になるのか。nncrmか？nnncrm、n5crmとかschemeの仕様みたいになっていくのかと小一時間（略 テストが無い テストぉ？そんなお上品なもんなんざぁ、とんとお目にかかったことねーなぁ？ バリデーションが無い バリデーション？そんなお上品なもんなんざぁ（略 サーバーがrootログインの許可＋IP制限している セキュリティを高めたいのか低めたいのかどっちなのか。使い辛いわ。 バージョン管理システムがよくわかってない なぜトップにぶち撒けられてる？trunkはどこ？branchesとtagsはなぜ空？ メソッドが大文字から始まる あんた絶対Windows畑から来たね？同じ調子でPHP書かれても困るんだヨォ。 全テーブルに共通のプレフィックスが付いている いや、データベース名が
Mac OS Xを使う理由とDebianを使う理由 - komagataのブログ
何がLinuxデスクトップを殺したか（What Killed the Linux Desktop 日本語訳） 要約すると、(a) 第一の要因：物事があまりに早く変化し、オープンソースも独占ソフトウェアも同じように壊れる。(b) Linux ディストリビューション間の非互換性。 これがデスクトップ分野で Linux をターゲットとしようとするサードパーティの開発者のエコシステムを殺した。一度は挑戦して、「トップ」ディストロや寛容な人なら「トップ3」ディストロをサポートするのに最善を尽くすだろう。それで知ることになるのは、6ヵ月後にはそのソフトウェアがもう動かないということだけ。 何か覚えのある感覚。僕（ら）はサーバー用OSとしてDebianを選ぶのにも同じような考えをしているなと思いました。 Linuxはサーバー分野では成功して、沢山のサードパーティー開発者（僕も）に使われている。サーバー分
ローカルのWebサーバーを簡単にネットからアクセス可能にするproxylocalが便利 - komagataのブログ
ProxyLocal ProxyLocal could proxy your local web-server and make it publicly available over the internet. ローカルのWebサーバーに他人にちょっとアクセスして欲しい時(何かの実験中とか)に便利なgem。 # app.rb: require 'rubygems' require 'sinatra' get '/' do ' ┐(´ー｀)┌' end こういう糞アプリがあったとして、まずローカルで立ち上げる。 % ruby app.rb == Sinatra/1.2.6 has taken the stage on 4567 for development with backup from Thin >> Thin web server (v1.2.11 codename Bat-Shit
screen - 起動時に5枚window立ち上げる。ただし0、テメーは駄目だ。 - komagataのブログ
昨日の生放送で@n0tsさんにscreenの便利な設定を教えてもらいました。 .screenrc screen -t vi 1 screen -t zsh 2 screen -t db 3 screen -t repl 4 screen -t server 5 select 1 こう書くと、screenを立ち上げた時に自動的に5枚windowが用意されて1が選択されている状態になります。特に僕はwindow 0を使ってなかったし、かならず5毎立ち上げるのが癖になっていたのでとても便利になりました。 それぞれのwindowの使い道も何故か自分の中で決まってるので初期タイトルにそれを付けておきました。
そろそろヌーラボについてガツンと言っておく - p0t
「Backlogは素晴らしい。」 そもそもBacklogの素晴らしさに嫉妬の炎を燃やしていたところにCacooというサービスが出てきた。それ以降、僕らは自分達の仕事にCacooを使っている。（Webアプリのワイヤーフレームを書くため） これも株式会社ヌーラボのサービスだという。 僕は別にヌーラボの回し者でも知り合いでも何でもない。「Web+DB Pressでヌーラボって名前をちょっと見たことあるなー」ぐらい。 個人やSOHO、LLCといった小さなグループがインターネットを使って共同作業する機会がこれからさらに増えてくのは間違いない。ローカルアプリよりWebアプリ。社内サーバーより社外サーバー。社外サーバーよりASP／SaaSの方が管理が楽。 数年前から海外のITベンチャーがGithubスタックと呼ばれる複数の外部サービスを組み合わせて仕事をするというスタイルが広まってるらしい。しかもそれは
fork, merge, diff, patch, git, hgソースコラボ色々 - komagataのブログ
Help me, hackers!をやり始めてからパッチ送ったり、貰ったり、pull requestしたり、されたり、ソースを通したコミュニケーションが増えて楽しい。 今まではpull requestとかpatchとか滅多にやらないからやり方忘れててやる度ににググってた。 ソースコラボのための色々な方法 gitでpatchを作る 適当にファイルを修正してリポジトリのルートで % git diff > foo.patch gitで作ったpatchを当てる 同じくリポジトリのルートで % patch -p1 < foo.patch Mercurialでpatchを作る 適当にファイルを修正してリポジトリのルートで % hg diff > foo.patch Mercurialで作ったpatchを当てる 同じくリポジトリのルートで % patch -p1 < foo.patch githubでf
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
svnの日本語ファイル名問題と1.7のスゴイ変更点 - komagataのブログ