  |
はてなキーワード: Railsとは
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
https://moneyforward.com/engineers_blog/2016/07/07/ruby-core-201606/
[#11741] Migrate Ruby to Git from Subversion
またこれか。
いつも「なぜRubyはGitに移行しないんですか」とかいうスレッドが立つんですけど、結論としては簡単で、移行するモチベーションがある人がいない。外野でガヤガヤ言うだけの人がどんなにたくさんいても無意味で、きちんと結果にコミットしていく係になるだけの気概のある人が必要で、そういう人が出てこない限りは何も変わらないと思います。
ひとしきりゲラゲラ笑ったあとゾッとするよね。生産性の低い方法をとりつづけることを変えようとしない、コミッタ陣のその老害っぷりに。
「SVNからGitに移行する」というのはそれ自体は開発手法の変化において本質的とは思わない。重要なのは、パッチをGitHubのpull-requestやGitLabのmerge-requestのような、差分を見ながら細かく議論できるウェブインターフェイスを使って適用していくことだと思ってる。だからGitに移行したいというリクエストを「またこれか」「移行するモチベーションがある人がいない」で済ませるのは、そういうpull-requestベースの開発手法をよしととしていないってことでしょ。それでいいの？
別におれはRubyコミッタじゃないしパッチ送ったこともないし、Git移行の作業を手伝うつもりもないよ。だって関係ないもん。ただ、いちRailsユーザとしてこのRuby開発陣の老害化にはちょっと背筋が寒くなる。自分たちが老害化していることについて、もっと危機感をおぼえたほうがいいんじゃないのかな。
この記事を読んだ。
http://anond.hatelabo.jp/20160619185731
元COBOLエンジニア、現Rubyエンジニアとして増田の記事がどうしても許せなかったので反応してみる。
この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。
汎用系の現場でもRubyの現場でも優秀な人はたくさんいたし。
今では信じられないほどの経験を当時（といっても2年前）はしていた。
改めて今、RubyというかRailsを始めてよかったなーと思う。
いやー、これが一番ひどかったな。
まず静的デバッグ（机上デバッグ）といってコンペアファイル、ソースコード、コンパイルログをそれぞれ紙出しして提出用（クライアント）、リーダー、上司用の3部印刷する。
全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。
そしてインデントもレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。
定規で計るんだよ。半角スペースが5ミリだったっけな。
それで5ミリずれてたら指摘するんだよ。目がつかれたよね。
っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。
これもびっくりだよね。
専属の社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。
ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。
ネットは使えない。現場に入る時も持ち物チェックとかあるしな。
常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。
まだまだあるんだけど、これだけでもひどい現場だったなーって思う。
そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。
Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。
この先もっともっとブラックボックスなフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。
今年で40歳。趣味で Rails や Android や iOS のアプリを書いてきた。
職業としてエンジニアとして生きていくことが叶うなら転身したい。
しかし基本的に一人でプログラミングしてきたので、チームでの開発はしたことがない。
地域柄あまり仕事に恵まれず、今の歳までエンジニアと無縁の仕事をしてきた。
エンジニアになるのはほとんど諦めかけていたが、最近になって自分の住んでいる地方でもそういった仕事が出てき始めた。
一応いろいろ手は動くという自負があるので、頭に転職の文字がよぎるようになった。
しかし年齢的に今から本職のエンジニアとして生きていくのは辛い部分があるだろうな、と思って躊躇してしまう。
今の仕事はある程度未来の予測がつくので、それを捨てていくことも気になる。
収入面はどうなのか、自分のような年齢の人が転身したケースがあるのか、同年齢のエンジニアの人がどのような状況にあるのか、分からないことばかり。
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。UIの共通化は？出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな！みんなモチベ低い！
ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ！！周知しよ、難癖つけられそう笑
追記 : 2015/08/22
でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。
よく技術者と営業の対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。
営業はキツイよなー、成果出なきゃやり甲斐が生まれないでしょ。
追記 : 2015/08/24
この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。
「一生面倒みる覚悟がないなら助けるな」
大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。
追記 : 2015/08/26
面談。褒められた。評価評価うるせぇ。評価＝給料だからあんま興味ねーよそこには。給料で転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身の経営者がいる会社に入りたかったなほんとに。
っかangularjsすごいいいなと。双方向データバインディングとHTML拡張。フロントと完全分離出来るのがあつい。
追記:2015/09/07
夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱な会社始まり。
僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい（近々、エグいの書く）。まぁ、回避したから問題ないけどさ。
追記:2015/09/16
ちょー出世した。事業責任者的な感じ。給料もめっちゃあがる。転職して半年、プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときにゴリ押し回避の方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。
これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。
追記:2015/09/30
今日、いろいろ発表された。なんか抜擢されたからおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手（俺も）。ちょっとガッカリ。自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代はスーパーエリートばかりなのになんかおかしいと思った。
もうasp mvc飽きたなー。angular楽しいからまだいいけど。
最近はrailsが楽しい！ちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ！但し、サイトいつ出来るかなー。
追記:2015/10/15
やっぱ感情的な人はあんまり好きじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしいからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議。
っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかんと人間的におかしくなるね。
追記:2015/10/19
いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ。調子乗ってたら激安家賃の家にすまねーだろぅがよぅ！
って感じで愚痴はこれまで。
つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラムの本質を突いていてjsも馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。
追記:2015/12/07
好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。
追記:2016/02/11
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。UIの共通化は？出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな！みんなモチベ低い！
ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ！！周知しよ、難癖つけられそう笑
追記 : 2015/08/22
でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。
よく技術者と営業の対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。
営業はキツイよなー、成果出なきゃやり甲斐が生まれないでしょ。
追記 : 2015/08/24
この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。
「一生面倒みる覚悟がないなら助けるな」
大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。
追記 : 2015/08/26
面談。褒められた。評価評価うるせぇ。評価＝給料だからあんま興味ねーよそこには。給料で転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身の経営者がいる会社に入りたかったなほんとに。
っかangularjsすごいいいなと。双方向データバインディングとHTML拡張。フロントと完全分離出来るのがあつい。
追記:2015/09/07
夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱な会社始まり。
僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい（近々、エグいの書く）。まぁ、回避したから問題ないけどさ。
追記:2015/09/16
ちょー出世した。事業責任者的な感じ。給料もめっちゃあがる。転職して半年、プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときにゴリ押し回避の方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。
これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。
追記:2015/09/30
今日、いろいろ発表された。なんか抜擢されたからおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手（俺も）。ちょっとガッカリ。自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代はスーパーエリートばかりなのになんかおかしいと思った。
もうasp mvc飽きたなー。angular楽しいからまだいいけど。
最近はrailsが楽しい！ちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ！但し、サイトいつ出来るかなー。
追記:2015/10/15
やっぱ感情的な人はあんまり好きじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしいからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議。
っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかんと人間的におかしくなるね。
追記:2015/10/19
いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ。調子乗ってたら激安家賃の家にすまねーだろぅがよぅ！
って感じで愚痴はこれまで。
つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラムの本質を突いていてjsも馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。
追記:2015/12/07
好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。
追記:2016/02/11
http://www.lancers.jp/work/detail/953274
【月額単価】①～60万（スキル見合い）②〜70万（スキル見合い）
【備考】
・PHPができてRuby on Railsを学びたい方歓迎
・新しい技術が好きな方歓迎
↑
でも地雷の臭がするんだよなあ。
これrailsができる人じゃなくて学びたい人まで範囲を広げて募集してるんだよね。
いやあ怖いわああああ。
単価も釣りだろう。
railsでIDE強制されたりしたらどうしよう。vimしか使えない。
つうかランサーズって派遣の求人出したらアウトなんじゃなかったっけ？
クラウドソーシングって他で相手にされないようなレベルの仕事を依頼して、無知が提案する。
月8000円で募集しているのですが、作業量に比べて安すぎるでしょうか。
http://crowdworks.jp/consultation/threads/4349
こういう裏技を使えばタダで納品物を手に入れられるという事例↓
https://www.lancers.jp/consultation/detail/1144
そもそも有名なクラウドソーシングサイトでは仮払い制度というのがあるのだが、仮払いされて無くても納品できてしまうというシステムがおかしい。
仮払いする前に作業するなじゃなくてシステム側で仮払しないと納品できない、納品物を確認できないようにするべきだ。
これは運営側の怠惰である。この欠陥システムによって報酬が支払われずに泣き寝入りしている人達がいるっていうのに。
業務委託とはいえ、自分でその単価で出来もしないようなことを他人にやらせようとする人の神経が理解できない。
厚生労働省も本腰で何かしらのルール作りをしたほうが良いだろう。
クラウドソーシングでお仕事をしなくても相談室を眺めるだけでニュースにはならないネタが流れてくるのでチェックすると話のネタにはなる。
ランサーズの相談室 http://www.lancers.jp/consultation
クラウドワークスの相談室 http://crowdworks.jp/consultation
何を作りたいかというとマルチプレイヤーのブラウザゲームが作りたいんだよね。
俺の開発用のceleron 1コアのメモリ1GB環境では重すぎる。
isoファイルを10000個同時にダウンロードしてるぐらい重すぎる。
ページの読込みがなかなか完了しない。
こんなクソ重いフレームワークはそれなりのサーバスペックがないとパフォーマンスに影響が出すぎるので除外したい。
phpのフレームワーク一般に言えるんだけどプロジェクト毎にプロジェクトルートのなかにフレームワークのコアファイルを置くのがなんか嫌だ。
nodejsはシングルスレッドなので負荷の高いサイトで使うのは厳しそう。
pythonでもgolangでもwebsocketは使えるのでnodejsにこだわる必要もないしvert.xを使う選択肢もある。
日本ではvert.xの話題あんまり盛り上がってないよね。どこかの企業さんが実践で使いましたって記事を書いたら会社の知名度が上がると思う。
scala,golang,elixirこの3つの選択肢でいいのかな。
でも負荷の高いブラウザゲームやってる会社ってrailsとかphpだよね。
redisをうまく活用しとけばあんまりそれ以外でボトルネックとなるようなことって無いのかな。
スクエニさんのオンラインのドラクエもどうやってるんだろうね。
あと海外のブラウザゲームってほとんどがaws使ってるのでaws使えばいいのかな。
でも怖いよね高額料金を請求されたらさ。
金儲けの為にサイトを作らないとawsは使ってられない気がする。
正直「未経験でも数ヶ月でエンジニアに！」という記事自体がハズレがほとんどという印象があるけど、プログラミングに興味を持ってくれているのは嬉しい。
ただ、あの手の記事はPR目当てなことがほとんどなので、あまり当てにしない方がいいと思う。
「プログラマが知るべき10の〜」といったものもあるけど、ひとつも知らなくていい。少なくとも初心者の頃は。
vim は非常に良いエディタだと思うが、初心者向きではないのでお勧めしない。
無料で使えるものとしては atom あたりがいいんじゃないかと思うけど、好きなエディタがあるならそれでいい。
git や github は確かに超重要なんだけど、これもまともにプログラム動かないうちは手を出さなくていい。
プログラムに限らないけど、何かの学習ってのはひとつのことがとりあえず満足にできるようになるまで手を広げない。これが重要。
参考書もあれこれ買ってしまう人がいるけど、せいぜいひとつふたつに絞ってじっくり何周も繰り返した方が良い。
それと、他人は関係ないので成長の早い他の誰かのことは気にしない。
運動神経良くてどんなスポーツでもすぐこなせる奴ってクラスに一人はいたよね？彼と増田は違う人なので、比べても仕方ない。
実際のプログラミング学習では、かなりの人がファーストステップで脱落する。
増田のように、情報の取捨選択が出来ないし、今出来ないことを調べるためのキーワードがわからないので検索できない。
なので、本当の意味での完全独学ってかなり難しい。
じゃあどうすればいいかっていうと、実際にメンター役がいてプログラミングを教えてくれる環境がやはり一番。
有料のスクールはさすがにそうそう手が出ない値段だけど、無料や薄謝で開催している初心者向け勉強会もある。
独学じゃなくなるけれど、セカンドステップやサードステップまで一気に行けるとだいぶ楽。
あとこれはRuby on Rails 限定になるけど、Rails Girls という 不定期開催のワークショップで使われている教材を使うのもいい。
「もっと効率のいい学習法があるんじゃないの？」「もっと簡単にマスターできるんじゃないの？」と思って情報漁っているのなら、
今すぐそれをやめて、プログラミングの勉強だけに時間を割いた方がいい。
もちろんモチベーション維持のために目先を変えたりするのは構わないんだけど、初心者のうちは新しい情報仕入れても活かせないし、混乱するだけだからね。
増田のように苦労しながらも頑張っている人をみると、すごいな、と思うよ。
こちらは仕事だから当たり前にやっているけれど、増田はそうじゃないからね。
応援しているので頑張って欲しい。
TECH::CAMP、CodeCAMP、TechAcademy、侍エンジニア塾について、下記のことを教えていただけないでしょうか。検索してはみたものの、やはり表に出てくるのはいいことが中心になってしまう様子でしたので、こちらならどうかなと思っています。
①教えてくれる方はどんな方でしょうか（教えることが専門の講師のような方でしょうか。現場の開発者の方がやってくださるのでしょうか。学生アルバイトのような方でしょうか。もしもいろいろな人がいる場合には割合とか聞いてみたいです）
②学習の環境（開発環境を自分のPCに用意するのは結構大変だと聞きました。こういったところはレクチャされるものでしょうか。それとも既に整った環境を渡されるとかCloud9のようなものを活用したりするのでしょうか）
③卒業したらプロになれそうか、ただの入り口だけでまだまだかかりそうか（プロになれると書かれているところもありますが、そんな短期間でなれるのだろうか）
④RubyやRailsのバージョンなどが新しいものなのか（よくわからないのですが新しい方がいいような話を聞いたもので。。。）
⑤卒業後にも改めて質問するような機会がお願いすればあるものでしょうか。
私の目標としてはプログラマーに転職したいので、プロの端くれに加われるようになりたいです。少なくともプロの中に混ざった時に酷く足手まといにならないレベルになれるかは気にしています。もし今まで卒業された方から意見聞ければ嬉しいです。「今xxxな職場にいるよ」などあれば凄く参考になります。基本は通ったりすることを考えています。オンラインだけでもすごく効果があるならそれもいいなと思っています。
大人向けのエンタメな動画をキュレーションするサイトを作ってみました。
18歳未満の人はみちゃだめです
このサイトはRailsで作ってherokuに乗せてみたんですが、いかんせん遅い。
もちろんherokuは札束で叩けばいくらでも早くなるんだけどそんなに予算もないし、そもそもそんなお金あったらこんなことしてない。
なのでどうにかしてお金を掛けずにサイトを高速化する方法を考えてたら1つアイデアが浮かんだのです。
それはサイト全体をCDNのCloudfrontに突っ込んでしまう事。
ルートドメインのDNS設定のCNAMEで、Cloudfrontのドメインを指定します。
そしてCloudfrontのオリジンをherokuのドメインに指定する。
こうすることでCSSとか画像ファイルだけでなく、HTMLも含めて全部のファイルをキャッシュすることができます。
そしてCloudfrontの設定で、HTMLファイルは10分とか1時間とか割と短めに設定して、
CSSとかJSとかは、Railsで作っているとMD5キャッシュが効いていて、勝手にキャッシュが無効化されるので、
1か月とかを指定すればよい。
効果としては、heroku単体でやるとHTMLファイルの応答が600msぐらいかかっていたのが、Cloudfrontでキャッシュさせると60msぐらいで帰ってくる。
もう超早い。10倍速い。
あとgzip配信したいので、gemでheroku-deflaterを入れる。
このgemはすごくて、herokuに乗っていると勝手にgzipに圧縮してくれる。
これによってCloudfrontの利用料を節約する。
僕のサイトの場合、このherokuのサーバーから配信しているのは、HTMLとCSSが1ファイルとあと画像が1つで合わせて10kBぐらいしかない。
こんだけだと、Cloudfrontの料金は100万PVでも1000円いかないぐらい。
herokuを札束で叩くのと違って、従量課金なのであらかじめ高いお金を払っておく必要もないし、
普段は自社サービスでRailsエンジニアやっていて、コードを書いていることが多いのだけどたまにミドルウェアも設定ファイルをいじっている。
今に至るまでに、プライベートでRailsアプリを書いてVPSを借りてcapistranoでデプロイする、というのを3サイトほど行ってRailsはもういいかなって感じがしてる。AWS童貞なのだけど高くて個人では手が出せません。
js、coffee終了な匂いするしちょっと近くに寄りたくない気分。
Linuxサーバについてはもっと知見を深めたいとは思っていて、とりあえず今は http://www.usupi.org/sysad/backno.html を順番に読んでなるほどって感じ。これを読み終わったら何がいいのか。
LaravelやCodeIgniterやFuelphpやCakePHPなど、プロジェクトごとにフレームワークをインストールしなければならないので、使い回しが出来ない。
Zend Frameworkはそんなことないが、雛形がないのでルールを決めないととんでもないコードを生む。
限られた容量のレンタルサーバを使うときにLaravelを置くだけで15MB以上消費するのが気になる。
人気なフレームワークLaravelやsymfonyはCeleron 1コア、メモリ1GBの環境では重かった。
HTMLとCSSはまぁつかえるかなってところまでは来ました。（CSSは全部とは言わないですけど、本見ながらベンダープリフェックスでブラウザ対応とかはできます）
問題が、javascriptなんですよ
これなんていうか、なにをどうすればjavascriptできますよってレベルになれるのか皆目わからない状態で
jqueryってのでお遊び程度のアニメーションとかはできるんですけどだからなんだって話だし
世間のWEB制作サイト会社ってのは、参考書とかにのってるレベルのもので就活してきた野郎どう思います？
おいおいJqueryしか使えねーのにのこのこ着やがってくそ野郎って感じですかね
あと参考書って作って覚えよう系はなんで総じてjqueryなんですかね
素のjavascriptの本でそれやってくれてる本あんまないですよね。
はてな界隈だとなんかすごいAnglerとかいっぱいあるじゃないですか
reactだとかbabelがどうとか
正直どうしたらjavascriptできますってレベルに行けるのかわからないです
あとphp覚えなきゃですよね。rubyのほうがいいのかなって思ったりもしましたけど
phpって作って覚えよう系の参考書おおくていいですよね。rubyはそういうのないわけではないですけど、いきなりrailsとか飛ぶ本が多いですね。
まぁ結局ぼくはハッカー的な人間じゃないし、phpつかうのがいいんでしょうね
そんでwebにゴミまくなとかruby使ってる人にたたかれる人生が始まるのかなって思ってます
とりあえずjQueryものにして、教えていただいたちょっとむずかしめなサイトですけど読みながら素のJavascriptをいじっていきます
