プログラミング教育の必修化は「不要」だが「必要」
最近、政府がプログラミングを2020年から義務教育で必修化する方針を示したことで、改めて子供向けのプログラミング教育に関する議論が盛んになっています。 個人的な意見を述べさせてもらうと、多くの子供にとって、プログラミング教育は直接的には不要だと思います。大半の子供は職業プログラマになるわけではありません。プログラミングのスキルを必要とするエンジニアや研究者になる子供も限られるでしょう。 「プログラミングは論理的思考能力を鍛える」という意見がありますが、それなら算数や数学で十分です。ほとんどの子供にとってプログラミングは、例えば国語の時間の「習字」と同レベルの存在になると予想します。 しかし、だからこそプログラミングの必修化が必要だと考えます。義務教育でプログラミングを教えなければ、多くの人はプログラミングを経験する機会を一生持てないかもしれないからです。 もし、国語の時間に習字がなければ、
OSS についてあれこれ
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
1時間以内に解けなければプログラマ失格となってしまう5つの問題が話題に | ソフトアンテナ
プログラマの素養を確認するための簡単な問題として有名な「FizzBuz」問題。ただしこれだけ有名になってしまうと、プログラムの能力を試験するための新たな問題が必要とされているかもしれません。 経験豊富なソフトウェア開発者、Santiago L. Valdarrama氏が、「ソフトウェアエンジニアならば1時間以内に解けなければいけない5つの問題」を出題し、Redditなどで話題となっています。 その5つの問題は以下の通りです。 問題1 forループ、whileループ、および再帰を使用して、リスト内の数字の合計を計算する3つの関数を記述せよ。 問題2 交互に要素を取ることで、2つのリストを結合する関数を記述せよ。例えば [a, b, c]と[1, 2, 3]という2つのリストを与えると、関数は [a, 1, b, 2, c, 3]を返す。 問題3 最初の100個のフィボナッチ数のリストを計算す
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
圏論とプログラミング読書会#2 資料
1. けんろんどくしょかい #2 (2014/12/11) 直和集合について / ラムダ計算のさわり / 型なしラムダ計算 数学的厳密性は放棄します @gomi_ningen 3. #2-1 前回躓いた直和集合について 直和集合(direct sum) 集合A, Bに属さない 要素 * を考える A* = (A, *) B* = (*, B) とすると 直和集合 A + B = A* ∪ B* つまり A* の各要素 と B* の 各要素すべてを 集めたものが直和集合になります 4. #2-1 前回躓いた直和集合について 直和集合(direct sum) 集合A, Bに属さない 要素 * を考える A* = (A, *) B* = (*, B) とすると 直和集合 A + B = A* ∪ B* つまり A* の各要素 と B* の 各要素すべてを 集めたものが直和集合になります なぜこう
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
就職面接でプログラムの解読を求められた！ | POSTD
長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました（「解読してみろ」ということでしょう）。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。
不完全にしておよそ正しくないプログラミング言語小史
1801 – ジョセフ・マリー・ジャカールがパンチカードを使った織機によってタペストリーに"hello, world"と織り出す。しかしラッダイト (当時のRedditer) たちは、テールリカージョン、並行処理、大文字小文字の区別を欠いていたため、さほど感心しなかった。 1842 – エイダ・ラブレスが最初のプログラムを書く。彼女の努力は、プログラムを実行するコンピュータが実のところ存在しないというマイナーな問題のために頓挫した。後にエンタープライズアーキテクトたちはプログラムをUMLで書くために彼女のテクニックを再び学ぶことになる。 1936 – アラン・チューリングが存在しうるあらゆるプログラミング言語を発明するが、特許化する前に英国情報部員(後の007)によって抹殺される。 1936 – アロンゾ・チャーチも存在しうるあらゆる言語を発明しているが、より巧みに行った。チャーチのラムダ
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
型安全性とは何か | POSTD
以前書いた（C言語についての） メモリ安全性について定義した記事 について、型安全性について説明する記事も投稿してほしいというコメントがありました。型安全性についてはかなりよく知られてきていると思いますが、ズバリこうだと簡単に定義できるほどにはまだ理解が浸透していません。特に誰かが”Javaは型安全な言語だ”と言った場合、これは厳密に何を意味するのでしょう。全ての型安全な言語はある意味”同じ”と言えるでしょうか。ある特定の言語について、そして一般的な意味で、あなたを悩ませる型安全性とは何でしょうか。 実際のところ、型安全性が何を意味するのかは言語の型システムの定義によります。最もシンプルなケースでは、型安全性はプログラムの動作が正しく定義されるように保証します。もっと一般的な話をすると（この記事ではそのあたりをカバーするつもりですが）、言語の型システムはそのプログラムの正確さと安全性を推論
モナド教
前提知識：モナド モナドを理解せずともモナド教を信ずることは出来ますが，理解していればより深く納得できるでしょう． 操作 :: 型 -> 型 は，"型"から"型"へ写す"操作"の存在を表します． モナドの文脈 m が必要とする2つの操作： return :: a -> m a で，値を保ちつつ文脈 m の中に入れ込むことが出来ます． (=<<) :: (a -> m b) -> (m a -> m b) で，「値を文脈に入った別の値へ写す操作」を「文脈に入った値を同じ文脈に入った別の値へ写す操作」に変換します． id :: a -> a は値をそのまま返す操作です． id を =<< で変換して得られる操作 join :: m (m a) -> m a で，二重に文脈に入った値を一重の文脈に入った値に戻すことが出来ます． 文脈の値から生の値を取り出す型 m a -> a を持つ操作は，一般
スクールガールストライカーズの 内製クライアントエンジン
近年、ハイスペックなスマートフォン、高品質なネットワークが普及し、それによりモバイルゲームの制作手法やそれを取り巻く環境も変化してきました。スクウェア・エニックスでは、そのような環境の変化に対して、日々新たなチャレンジをし続けています。そして、このようなスピード感溢れる業界の流れには、会社の枠を超えた技術情報の共有、交流が欠かせないと感じております。 そこでこの夏、社内のエンジニア・テクニカルディレクターによる最新のモバイル開発の技術情報や社内モバイルエンジン、開発秘話によるセッションをメインに、スクウェア・エニックス モバイル オープンカンファレンスを開催する運びとなりました。また、セッションの後は登壇する弊社スタッフと直接ディスカッションやフリートークができる場を設けております。この機会にスクウェア・エニックスという会社についても、より詳しく知って頂ければ幸いです。 マネージャー・テク
「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い - Qiita
はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指
【shi3z日記】いまどきのオトコノコがプログラミングを覚えるきっかけ:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
shi3zです。 最近、急に周囲が「プログラミング教育しなきゃしなきゃしなきゃ・・・」と騒ぎ始め、ようやく人類総プログラマー化計画もこの段階まで進んだか・・・とほくそ笑んでいたのですが、なんて言うのかな。いくつか子供向けにプログラミングを教えているイベントに参加して、子供達の笑顔を見つつも、「アレ?こんなんだったっけ?」と思い始めてしまいました。 というのも、みんな「習い事の顔」をしてるんですよ。 たとえば、僕の子供の時も、なぜか英語の教室に通わされていて、まあ教室自体も楽しくやろう、みたいなホスピタリティに溢れたりしてるんですよね。 それで毎週、英語の教室に行っては、帰って来て、「英語楽しかった?」と聞かれ、僕も笑顔で「うん!」と言うわけです。
オブジェクト指向だけじゃない開発宣言 - uehaj's blog
Manifesto for Not Only Object-Oriented Development、オブジェクト指向だけじゃない開発宣言、というのが出てましたのでごにょと訳してみました*1。 オブジェクト指向だけじゃない開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 クラスよりも、関数と型を、 可変性よりも、純粋性を、 継承よりも、コンポジションを、 メソッドディスパッチよりも、高階関数を、 nullよりも、Optionを、 価値とする。すなわち、左記のことがらに価値があることを認めながらも(但しnullは除くが)、私たちは右記のことがらにより価値をおく。 内容は、「今どきのオブジェクト指向開発宣言」と名乗ってもあんまり違和感ないっす。 ただし、null、おめ
PicoPicoGameEngine
ピコピココード g=ppgraph B=ppscreen:size() Bw=B.width Bh=B.height tex=pptex:load("main.png") function set(p,d) local r r=ppsprite.new(tex) r:pos(p) r.d=d r.t=100 r:tile(2) r.idle=function(s) s:loopAnime(0.1,{2,3,4}) s:move(s.d) if not s.tane then s.d=s.d*0.98 end s.t=s.t-1 if s.t<0 then if s.tane then for j=1,5 do for i=1,360,15 do local x,y x=math.sin(i/180*math.pi) y=math.cos(i/180*math.pi) set(s,pppoi
お茶の水女子大学 理学部 情報科学科 准教授 浅井健一さんインタビュー
プログラミングをどのような観点に着目して学生に学んでほしいとお考えですか？またそれを落とし込むためのどのような教育を実施していますか？ 何かしらのソフトウェアを制作する際、それが何をするものなのか、一番外側の部分をしっかりと把握して全体をとらえること、それを構造的に分解して個々のパーツをきちんと組み上げること、そして最後にきちんとテストをして正しく動くことを確認するという流れをしっかりと学んで欲しいです。 そのために、お茶の水女子大学 理学部 情報科学科では C を中心にしつつ Java や関数型言語 OCaml などいろいろな言語を使って講義をしています。 C では、ポインタ操作やメモリ構造を意識したプログラミングなど低レベルの記述を求められますが、情報科学科を卒業したからにはそういったことも扱える人になって欲しいです。 一方で、より抽象度の高い言語を使うことで、細部にとらわれずに高度な
Javaプログラミング入門
本書は著者が非常勤講師を担当した大学の講義資料を再構成したもの。 理工系学部の学部1年生が初めて計算機室でプログラミング科目に向かうことを想定して、プログラミングの初歩的な知識がまとめられおり、各章においてゲーム性のある親しみやすいサンプルプログラムを掲載し、遊びながらプログラミングに接することができるよう構成されている。 本著作の著作権は著者が保持しています。 通常の閲覧以外の利用については、お茶の水女子大学附属図書館にお問い合わせください。 Copyright of this work is retained by the author. If you wish to use this material for purposes other than reading, please contact Ochanomizu University Library.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発効率アンチパターン
