高校で使われているプログラミングの教科書を全部購入して比較 (情報の科学)
Jul 29, 2018 義務教育ではないものの、高校ではプログラミング教育を含むIT教育が「情報」という教科として2003年から実施されてきています。 今回は情報の教科書を再び大人買いしましたので、全ての教科書に目を通した上でそれぞれの教科書の特徴を見ていきます。 以前の記事でも触れましたが、教科書は教科書会社が学習指導要領を元に作成し、教科書検定を受けたものが各学校によって採択され使用されます。 教科書に掲載されているからといってその内容がそのまま授業で行われるわけではないのは注意が必要です。 今回はその中でも平成28年に検定を受け、現在使用されている下記の6つの教科書を紹介します。 前置きが長くなりそうなので、各教科書について見たい方はジャンプしてください。 東京書籍 - 情報の科学 [情科306] 実教出版 - 最新 情報の科学 新訂版 [情科307] 実教出版 - 情報の科学 新
An Introduction to Existential Types
Parametric polymorphism is now widely known in the programming community (often by the alternate name generics). They allow one to create types parameterized by another type (e.g. a generic list type), along with functions that work on any type (e.g. the functional programming mainstays map, filter, and reduce ). You may have also heard them called universal types. This last nomenclature comes fro
Gitのつくりかた | メルカリエンジニアリング
はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか？と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals
Mac、iOSで、rand()関数の疑似乱数アルゴリズムがヘン！ - Qiita
話の発端は、StackOverflowの、この質問にあった。 StackOverflow 日本語版 - c言語での乱数生成 質問に対する回答は、きわめて単純で、rand()関数を、取得したい乱数の個数分、呼んでやりましょうというもの。 いちおう、XcodeのCommand Line Toolで、サンプルコードを作って、それを実行してみて、ちゃんと意図したとおりの結果になることを確認する。が、ここで奇妙なことに気づく。 何度実行しても、初項が4になる。 試しに、こんなC言語のコードを書いて、Xcodeで実行してみる。 #include <stdio.h> #include <stdlib.h> #include <time.h> int main(int argc, const char * argv[]) { unsigned int i; unsigned int seed = (uns
スタートアップや新規事業に限った技術的負債の考え方 | F's Garage
最近のエンジニアの感覚だと、技術的負債というのを極端に嫌うケースがあるそうですね。 技術的負債とは… 行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。 wikipedia – 技術的負債 この言葉は確かにキャッチーだ。プログラムなんて動けばいいでしょという上司に楯突く時に使いやすい武器になりそうだ。 「負債」という言葉はなかなか面白い比喩である。 では少し、負債という言葉について調べてみると、こういうのが見つかる。 負債は借入金や買掛金などの法律上の債務であるとイメージされがちですが、厳密にいったらこれは間違いです。 すなわち負債とは、法律上の債務に限らず、いずれ会社が負担することになるであろう経済的負担で貨幣額で合理的に評価できるものが該当します。 http://financial.mook.to/accounti
すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
GitHubなどで使える:+1:するバッジサービスを作った
[](https://voting-badge.herokuapp.com/vote?url=https://github.com/azu/voting-badge) GitHub Issueで賛成などを :+1: と書いてコメントすることが良くあります。 投票ボタン的な機能としてそういうのが欲しかったので、Travis CIのバッジのように表示+投票できるボタンを作りました。 Voting Badge 上記にアクセスしてURL(実はキーなら何でもいい)を書くとバッジのURLを作ってくれます。 img + link というよく見るバッジの仕組みと同じです。 なぜ作ったか 最近ブログをGitHub Pagesに移動し
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
何でもデバッグできるようになるスキル - ワザノバ | wazanova
https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ（apt, yum, gem等）レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい
迫り来る「forおじさん」と呼ばれる時代 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今となっては、プログラマにとってなんとなく理解して利用できることが当たり前になりつつあるオブジェクト指向ですが、しかし、それこそ今から数年前には、この「オブジェクト指向」というのは、いわばおじさん達が変な方針を打ち出したりして「え、それ変な実装方針じゃねえの」というツッコミが入ったりしていました(ちなみにそのあたりの雰囲気については、この記事を読むと分かりやすいでしょう)。 もちろん、これはこれなりにメリットがあるのかもしれませんが、しかしそれはまた別のオブジェクト指向を利用したモデリングと比較してのことであって、「これだけでいい」と考える人はいないでしょう。 原則: だってそのほうが開発しやすいから まず最初に原則を考える必要があります。まずひとつに、必ずしもオブジェクト指向が正しいモデリングの方法ではないこと。少なくとも自分が思うに、オブジェクト指向を使うべき理由というのは、
_%25E9%2580%2580%25E8%2581%25B7_)
就活日記 (12) 退職 - laiso
目次: 就活日記 (0) エントリー - laiso そろそろ就職するにあたって、退職しないと就職することができないので就職する前にまず退職をしました。 思えば私のプログラマーとしてのキャリアも6年ばかりとなりました。 ところで私は当時勉強が出来ない奴はプログラマになれ！ - IT戦記 を読んでプログラマになったクチで、この記事にはたいへん励まされました。 しかし当然順風満帆なプログラマー人生ともいえず。マイナスからのスタートでした。これはとくに精神面や比喩的な意味というわけではなく、低賃金の肉体労働をしばらく生業にしていたため単に総資産がマイナスでした。 そもそも私が一番最初にプログラマーをこころざしたのは、うだつが上がらない十代を地方ですごしていた時分です。 社会的脱落者として場当たり的に日銭を稼ぎ、賃料が不要な家で暮していた為稼いたぶんをそのままビデオゲーム筐体に投入する、などという
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
Jim Weirich さんから学ぶ DI(Dependency Injection) - わからん
PHP コミュニティでは今、DI コンテナが花盛りです。良い機会と捉え、勉強しています。このブログ記事では、Jim Weirich さんの O’Reilly Open Source Convention August 1-5, 2005 での Vitally Important or Totally Irrelevant? というタイトルのプレゼン資料を紹介します。完全な翻訳ではなく、省略したりおぎなったりしています。間違いはコメント欄などでご指摘下さい。 この資料では、動的型付け言語である Ruby にとって DI は重要な設計方針なのかを、静的型付け言語である Java のサンプルコードを引き合いに出し論じています。これを読むことで、DI とは何かを(実際に動く)コードレベルから理解することができました。また、Ruby ならではの実装を知ることができました。しかし、Ruby にとって
いまさら聞けない「オブジェクト指向設計の3つのコツ」～オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog
CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日本のITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました！ 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
コード内で「現時刻」を気軽に取得してはいけない | Nekoya press
日付を扱う処理についていろいろまとめたついでに、わりと簡単なことだけど知らないと落とし穴にハマる系のネタを。 日頃いろいろな処理を書いていて、現時刻を扱うこともは少なくないはずです。ですが、これを適当にやっていると困ることが多々あります。 実行中に「現時刻」を元にした処理が食い違う 例えばこんなコード。ログ集計とかやってるイメージです。 class Analyzer(object): def analyze(self): logfile = datetime.datetime.now().strftime('my_log_file.%H') self.save(self.analyze_logfile(logfile)) def save(self, result): now = datetime.datetime.now() self.result[now.hour] = result
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人は1ヶ月でエンジニアになれるのか
Goの変数名が短い理由（あるいはGoがほかの言語と違う理由） - Qiita
ヘビメタ英語を日常で使う風景
長文日記