プログラミング教育が必修化したら、まぁーた、「授業で教えていないので、これを使ったらダメ!」をやっちゃうんだろうなー。 そして、プログラミング嫌いを増やしちゃう、あれデス。 自分の氏名でさえ、授業で習っていない漢字を書いたらダメと言われるのと同じです(まじできちがいだと思う)。 英語の教師よりも、英語ができる生徒が毛嫌いされるのと同じです。 数学の教師よりも、数学ができる生徒が毛嫌いされるのと同じです。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
社内SEになった。 仕事を辞めて主夫業に勤しんでいたら、知り合いから声がかかった。 1人で社内システムを作ってきたおじいさんがあと数年で定年になるから、 引き継げないかとのこと。 メインのシステムはベンダーに委託してて、そのおじいさんが作っているのは、 メインシステムのデータを加工して2次利用しているものがほとんどとのことだった。 社内SEはなんとなく楽そうなイメージがあったので、就職した。 言語はエクセルVBAとVB.NET 1.0。 中身を見るとどちらもかなりやばい。 VBA編 ・ウォッチウインドウを知らないのか、変数はすべてセルに入れてる。 変数名はすべてRANGE("A1").valueみたいな感じで全く意味が分からない。 ・処理遷移がおかしい。 セルに1を入れる。そのセルのchangeイベントで処理が動くとか。 SHIFT+F2が無力化されてる。 ・なるべくワークシート関数で処理
if(param==0 && 判定(param2) || !param3){ //したいこと } みたいに3つぐらい条件がある場合、頭がパンクしそうになる。 この時こう考えている。 1:したいことをする条件は 2:paramが0 3:かつ 4:判定関数でparam2の条件を返して、true 5:またはparam3がfalseのときがtrueだから 6:trueだとだめなんだよね。falseが正しいんだ。でもfalseは偽なのに正? 8:あれ、何したいんだっけ。まぁいいや、とりあえず実行してエラーなら直そう。 7:実行。 8:あれ?なんか違う。何がおかしいんだ 1へ戻る。 これを3,4回繰り返してウアアアアアアアアアアアってなってしまう。 誰か助けて
「未経験でも数ヶ月でエンジニアに!」とかいう記事をよく見るわけで。 初心者向けweb開発記事のブックマーク数を見ていても人気なのが目に付く。 やはり何だかんだで「面白そう!」とか「こういう仕事やりたい!」っていう人が沢山いるんだなと実感する。 就職する事を目的にしていなくとも、趣味でプログラミングを習得しアプリ開発をしている人も多数目に付く。 素直に「凄い」としかいえない。 当人の勉強方法が優秀なのか、はたまた開発者との繋がりがあったりするのか検討も付かないが、まったくの素人なのにあれよあれよと成長し作り上げてしまう彼らの速度に驚かされる。 情報さえ得られれば未経験でも簡単にスキルが身につくのかと思いきや、実際そんな甘い話では無いわけで。 自身も興味はあったので、動画学習サイトなどを参考にウェブサイトを作成してみたのだが、しょうも無いところで動作が不安定になってしまったりと全くといって良い
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
コードを書くことコードを読むことコマンドラインをほぼ常に使うこと(「使わないわけないだろう」と思う人が多いと思うが、それができない人はそれよりも多い)ライブラリも可能な限り読むこともっとコードを読むことコピペしてもいいけど、コピペするコードの意味は絶対に把握すること自分の勤め先がクソなら、会社は辞めること(ある程度技術力があればどこでもやっていける)英語が読めること数学的・論理的思考をみにつけることオープンソースのコードを読むことなるべく根本的な概念を知ることひとつの言語に拘らず、何個も触ること(ひとつのパラダイムに固執する可能性がある)UNIX/Linuxをメインでつかうこと流行を追いかけ過ぎないこと(結局ソフトの上で踊らされているだけ)自分の知らない分野はいくらでもあると心得ること井の中の蛙にならないように心がけることマネジメント視点も取り入れること「他人のため」を考えること(独りよが
俺の半生大学の一般教養でPascalを習った程度。専門課程に入る前に文法はすっかり忘れた。専攻は都市工学だからその後プログラミングとは縁はなかった。卒業前に第一種情報処理技術者の資格だけはとれてたのでプログラミングの何たるかとかオブジェクト指向なんかも知識としては知ってた。 大学卒業後にデスクトップユーティリティーのメーカーで技術営業をやった。顧客に製品仕様を説明するのが主な仕事なのでパワポばかり使ってた。その会社ではLinuxのソフトも販売してたから、Linuxのコマンドは打てるようになった。そこでシェルスクリプトを習得しようと思ったがあえなく挫折。 その後ネットワーク機器のメーカーに転職。トラブルシューティングでLinuxをさらに使うようになった。そこではHTTPプロキシを主に扱っていたので、HTTPプロトコルについては一通り知識を身につけた。その知識を実際にLinux上でシミュレーシ
(あんま多くないみたいだから多分すぐ身バレしそうだけど書く) エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ? それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード(30〜50行程度のコードを3〜4ファイル)を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思
今週もやってまいりました。 全日本デスマーチ選手権。 日本中の兵どもが、プロジェクトを破壊するために死闘を尽くします。 本日は解説にギコさんをお呼びしております。 さぁ、ギコさん、ウンコーダ選手のまなざしはどうですか? 「いやー面接じゃなにもわかりませんからねぇ。どんな荒業が飛び出すか想像もできません」 では、注目してみてまいりましょう。 おっと!ウンコーダ選手、テストコードの記述を拒否!!!!! やったことがないから、できませません!!!!! でたーーーー!!開幕早々の大技だ! 「これはすごいですね。難しそうな作業は全部拒否するATフィールドを展開して、リーダを牽制しています」 おっと、リーダ、食い下がる。 しかし、理屈にならない理屈を並べて攻撃をかわします。 「面接でみせた、一見、口が上手くてコミュニケーションが得意そうにみえるという罠にはまりましたね。現場を離れた人が面接官だとよくひ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く