タグ

ブックマーク / blog.jnito.com (6)

  • 「業界の新入社員に向けた100文字程度のコメント」を考えるなら - give IT a try

    ツイッターを見てるとソニックガーデンの倉貫社長のこんなツイートが目に留まりました。 ある書店のフェアに向けて「業界の新入社員に向けた100文字程度のコメント」を依頼されてるけど、これを考えるのが思ったより難しくて苦戦してる。皆さんなら何を伝えますか?— Yoshihito Kuranuki (@kuranuki) April 17, 2012 なるほど、自分だったら何を書くかな〜と思い、ちょっと考えてみました。 100文字ぐらいだとこんな感じですかね。 Enjoy! 仕事を楽しんで下さい。自分が面白いと思える分野を見つけて下さい。もし楽しめないなら、なぜ楽しくないのか、どうすれば楽しくなるか考えてみて下さい。楽しまないと損ですよ。だからEnjoy! 何も考えずに書いた初期バージョンはこんな感じです。190文字ぐらいありました。 Enjoy! 仕事を楽しんでください。働きながら自分が面白いと

  • FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try

    はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに!? ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第1

    FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
  • プログラマ歴12年の僕が選んだ「10年経っても役立つ技術書17選」 - give IT a try

    はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「こので学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。(紛らわしくてご

    プログラマ歴12年の僕が選んだ「10年経っても役立つ技術書17選」 - give IT a try
  • Stack Overflowで世界を相手に腕試し - give IT a try

    はじめに 技術情報をググると結構な頻度でひっかかるStack Overflow。 みなさんも一度は見かけたことがあるのではないでしょうか? 僕も時々その内容を参考にしてきました。 最初は単なる海外のプログラマ向けQ&Aサイトぐらいにしか考えていなかったのですが、よく調べてみると色々と興味深い仕掛けや工夫がなされていることが分かりました。 Stack Overflowの概要は以下のサイトが参考になると思います。 『Stack Overflow』から学ぶ最近のコミュニティ構築術 | IDEA*IDEA 上のサイトの情報に加えて、実際に使ってみて気づいた点などを簡単にメモしていきます。 日人プログラマのためのStack Overflowガイド 先に断っておきますが、こちらは前振りです。 このエントリの題はずっと後ろの方に隠れています。。。 評価(Reputation) Stack Overf

  • 僕がサクラエディタからVimに乗り換えるまで - give IT a try

    はじめに 恐怖のエディタ、Vim。 僕はこの間までずっとサクラエディタを愛用していましたが、最近Vimを使うようになりました。 ええ、Vimです。あのVimです。Viでもいいけど。 Vim・・・使いこなしている人はそれだけで玄人っぽく見られる伝説のエディタ。 実際にVimを使えばすさまじいスピードのコーディングが可能になる。(らしい) しかしそんな憧れだけで手を出しても大半の技術者は全く手に負えず、すぐに尻尾を巻いて元のエディタに舞い戻ってしまう恐怖のエディタ。 それがVimである。 ・・・はい、僕の中でVimやViのイメージはそんな感じでした。 実際、Unix/Linuxマシンのターミナル上で何度か(いやいや)使ったことがありましたが、まあ扱いにくいのなんのって。 「カーソルは十字キーで動くけど、どうやって入力するの? 」 「えっ? "i"を押せ? 」 「入力が終わったらESC? なんで

    僕がサクラエディタからVimに乗り換えるまで - give IT a try
  • 「現場を変える?会社を変わる?」できることと、できないこと - give IT a try

    はじめに 先日のDevLOVE関西でもちょこっと絡ませてもらった@jyukutyoさんのブログがなかなか面白いと感じました。 「現場を変える・会社を変わる・SIから抜ける」何を選ぶのか - Fight the Future 書いてあることはほぼ同意です。 それに補足する形で僕の経験や考えをいくつか紹介してみます。 「信念がコンフリクトしている人」を変えるのはムリ まず、僕の経験上、一人の人間が現場を変えることは非常に難しいです。 一番困難、というか絶対ムリだと思ったのは「信念がコンフリクトしている人」を変えることです。 特にそれが上司だったり、部長クラスの人だと、転職する方が有力な選択肢になると思います。 例えば、アジャイルな開発スタイルを現場に導入したいと思っていても、「アジャイル開発なんて理想論だ。そんなお遊びで仕事が回るのは景気のいい会社だけだ。普通の会社は事前に仕様書を書いて開発を

    「現場を変える?会社を変わる?」できることと、できないこと - give IT a try
    chanpon0
    chanpon0 2012/11/19
  • 1