タグ

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

  • アウトプットのネタに困ったらこれ!?Ruby初心者向けのプログラミング問題を集めてみた(全10問) - give IT a try

    はじめに:「初心者は何をアウトプットすればいいの?」問題について 以前から何度か書いているのですが、Ruby初心者の方で「Rubyの勉強を始めました!アウトプットがんばります!」と言いつつ、実際はアウトプットしているのは、ほとんど書籍や他のサイトに書かれている内容を右から左へ丸写ししただけ、という方をよく見かけます。 その話題については、以下の記事で詳しくまとめているので、興味がある方はこちらをご覧ください。 blog.jnito.com qiita.com まあ、それはそれでさておき、「じゃあ、どうしたらいいの!?何をアウトプットすればあんたは満足するのさ!?」と思われる方も中にはおられるでしょう。 もちろん、その質問に対する回答についてはいろんなアプローチが考えられるのですが、今回は僕からひとつ、「アウトプット迷子」になっているプログラミング初心者さんに向けて、こんな提案をしてみたいと

    アウトプットのネタに困ったらこれ!?Ruby初心者向けのプログラミング問題を集めてみた(全10問) - give IT a try
    indication
    indication 2021/09/27
    初心者向け例題
  • Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try

    はじめに 先日、Rubyプログラマが職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は当にひどかった 今年は誰かな〜? → えっ、僕!? 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る(一人で解決しようとしない) リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策(設定の変更等)は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない&時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た

    Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try
    indication
    indication 2019/07/29
    いい話なうえに、地域に配慮した内容でなんかもう、すごい。ゲームも言及あり。はてブ コメントを見てさらに驚く。
  • ブログに書くか、Qiitaに書くか(技術系のネタを) - give IT a try

    はじめに ITエンジニアのみなさんは「常日頃からアウトプットすることが大事」という話をよく耳にすると思います。 僕自身もそういう話をよく言っていますし、実際にたくさんアウトプットしている方だと思います。 このとき、アウトプットするメディアは大きく分けて「自分のブログ」か「それ以外」になると思います。 日に住むITエンジニアであれば、自分のブログ以外のメディアとしてQiitaを使うことが多いでしょう。 このとき、選択肢は以下の3つになります。 自分のブログにだけ記事を書く 自分のブログとQiitaを使い分ける Qiitaにだけ記事を書く 僕は2のパターンですが、人によっては1か3の場合もあると思います。 僕のおすすめは1か2です。 3の「Qiitaだけ」という選択肢もアリと言えばアリなのですが、気を付けてアウトプットする必要があると思います。 というわけで、このエントリでは技術ネタのアウト

    ブログに書くか、Qiitaに書くか(技術系のネタを) - give IT a try
    indication
    indication 2018/03/24
    チュートリアルなことは最近全く書いていない。困ったことの内容は大抵stackoverflowで自作自演してる。ただ、未だに.netのdllのconfig話にアクセスが多いのには驚いている
  • ソフトウェア開発プロセス残酷物語 - give IT a try

    昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや人が直接手を動かすことはありませ

    indication
    indication 2012/08/27
    開発手法もトライ&エラー。エラー&エラーだったら、、のお話。泣けてくる
  • 2011-02-18 - ITは芸術だ レガシープログラマかどうかを判断する10項目

    ※2011.3.30追記 11個目の判断項目を追加しました。 また、「昔はね...」の補足説明を各項目に追加しました。 レガシープログラマ = モダンな言語のおいしい機能をうまく使いこなせていないプログラマ おいらは時々社内システムのコードレビューなんかをやっているのですが、「なんかちょっと前時代的だな〜」とか「ちょっと修正したらC言語でもコンパイルできそうだな〜」って思うことがよくあります。 おいらがレビューする言語は主にC#です。C#やJavaのような比較的モダンな言語のおいしい機能をうまく使いこなせていないプログラマを、ここでは「レガシープログラマ」と呼ぶことにします*1。 そこで、おいらがこれまでに見てきたコードの中から「これはレガシープログラマっぽい」と思った典型的な症例を10個11個挙げてみます。 レガシープログラマの判断項目 使われるローカル変数をすべてメソッドの最初に宣言す

    2011-02-18 - ITは芸術だ レガシープログラマかどうかを判断する10項目
    indication
    indication 2011/02/18
    最新を知っておいたほうがよい
  • 1