「Webプログラミングが面白いほどわかる本」を出版させてもらいました｜吉村 総一郎 (sifue)
N高等学校でプログラミングを教えているsifueと言います。本日「Webプログラミングが面白いほどわかる本」という、JavaScriptでプログラミング入門を終えたN高等学校の生徒が、本格的なWebプログラミングを学ぶための基礎知識を習得する部分をまとめた本を出版させてもらいました。N高等学校の生徒さんが1年目の9月ぐらいまでに習う内容となっています。 各所で話題となっていますN予備校プログラミング入門コースの、第1章部分は前書である「高校生からはじめるプログラミング」なのですが、この本は2章から3章の前半までがまとまった内容となっており、 ●Chapter1 Linuxの基本を身に付けようLinuxというOS/コンピューターの構成要素/コマンドでファイルを操作する/標準出力/viの使い方を学ぼう ●Chapter2 シェルプログラミングをやってみようシェルプログラミング/通信とネットワー
プログラマー向け最強フォント「M+」 | ソフトアンテナ
プログラミングに最適なフォントは何でしょうか。海外のブログ記事「The Best Font for Programming: M+」にて、プログラマー向けのベストフォントとして「M+」フォントが推奨されていました(Reddit)。 ブログによるとRetinaディスプレイのような高詳細ディスプレイで使うのに具合がよく(低解像度ではTerminusフォントが推薦されています)、0(ゼロ)とO(大文字のO)のような紛らわしい文字がはっきり区別できる点がお気に入りポイントの様子。 ↑このように。 実は、M+フォントは日本人が開発している日本語対応のフリーフォントです。海外発のフォントの場合アルファベットの見栄えはよくても日本語と合わせるとどうも…といったことが起こりがちですが、M+フォントだとそのような心配は不要だと思います。日本人開発者なら使わない手はないかもしれません。 M+フォントは、個人利
静的型付き言語プログラマから見た動的型付き言語 - あどけない話
およそ20年前にAlan Kay の講演をきいたことがある。印象に残ったのは、彼が引き合いに出した McLuhan の言葉だ。 I don't know who discovered water, but it wasn't a fish. (拙訳)誰が水を発見したかは知らないが、発見者が魚でなかったことは確かだ。 誰しも信念という水の中を泳ぐ魚のような存在だ。思い切って飛び跳ね空気に触れてみなれば、自分が信念という水の中にいることに気付かない。 ある手法の利点を語るには、その手法の欠点や、他の手法の利点や欠点とできるだけ客観的に比較しなければ説得力がない。ただ、これを実践するのは難しい。この記事では、客観的になれているか自問自答しながら、動的型付き言語と静的型付き言語について比較してみようと思う。 僕は静的な C 言語から、動的な Perl、Lisp、JavaScript を経て、現在で
コードを理解できない人間がソフトウエアの記事を書く怖さ
数年前、他社のプログラミング雑誌を書店で立ち読みしていたとき、その雑誌の編集後記を見て違和感を覚えました。「私はコードは全く理解できないが、間違っていそうな個所は編集者の勘でわかる」と書いてあったのです。「それはおかしいんじゃないか」と思いました。 好意的に解釈すれば、自分にはできないプログラミングができる執筆者に対する尊敬の念が、このような文章になったのかもしれません。編集者としての感覚を誇りたい気持ちもあったのでしょう。たしかに、編集業務の経験が長ければ、「何かがおかしい」という勘で誤りを発見できることがたまにあります。しかし、技術的な誤りをすべて勘で見つけられるわけがありません。 掲載するコードの内容が正しいかどうかをチェックするのは、プログラミング雑誌の編集者にとって重要な仕事の一つです。意味がわからない箇所があれば筆者に確認するべきでしょう。コードがわからないのは恥じるべきことで
オブジェクト指向プログラミングの時代に生まれて良かった
プログラムが単なる手続きの時代から オブジェクトによるコラボレーションを定義する時代に変わった。 でも、それだけじゃなかった。 オブジェクト指向プログラミングの時代でも、ただ窮屈な時代はあった。 クラスの概念に触れたときの意味の不明さから始まって 動物を継承した犬のせいで、オブジェクトは現実の物質から切り離されない誤解。 デザインパターンは、ただ世界を難しくとらえるためのパターンにしか見えなくて辛かった。 その時代のオブジェクトは、フレームワークという複雑な仕組みを構築するためのツールでしか無く プログラマは、オブジェクト指向プログラミングの申し子のようなフレームワークの上に、いるだけだった。 ただいるだけだった。 オブジェクト指向なんて概念の一切の無い、ただの実体定義する作業でしか無かった。手続き言語の時代と変わらない。 でも、本当に複雑なのは、フレームワークじゃない、表現すべき対象だっ
太一のコードの読み方メモ
太一のコードの読み方メモ 全体として太一が感覚的に実践している事を論理的に説明しようと試みている為、 説明の粒度が適切でなかったり一貫性が無いように見える部分があるかもしれない。 普段やっているけども書ききれていない事も多分きっとある。 コードを読むとは何か コードを嗜む コードを学ぶ 武器を手に入れる これは武器を手に入れるコードリーディングの話 武器とは何か プロジェクトで戦う為の道具となる知識 プロジェクト内における技能を示す為の道具となる知識 プロジェクトのやり方を自ら決められる様になる為の道具となる知識 権限と責任がバランスよく割当てられた時モチベーションは最大化する 何と戦うのか プロジェクトリスク プロジェクトをより良い状態にする為の基礎的な根拠となるのがコードである コードが全てではないが適切に動作するコードが無ければプロジェクトは終わらない これはつまり理想を体現する為の
新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く
ぼくは以前にIT関連の仕事をしたことがあって、ぼく自身はプログラムを組めるわけではないのだけれど、何人かのプログラマーさんと一緒にお仕事をさせて頂く機会があった。その中で生まれて初めてプログラマーという職業の方と交流させて頂いたのだけれど、彼らはなかなかにユニークで特異な個性の持ち主たちであった。もちろんプログラマーと一口に言っても色々なタイプがいて、必ずしもひとくくりにできるわけではないのだが、共通していたのは好奇心が旺盛で新しい物好きだということだった。そして少々気難しい面がありつつも、基本的にはポジティブで、明日に向かって色々なことを前向きに、精力的に取り組んでいる人が多かった。 そんな中で、特に親しくお話しさせて頂いたTさんというプログラマーがいて、この方もなかなかに個性的で、ご自分の意見や主張というものをはっきりと持っており、ITのみならず世の中に対しても一家言お持ちであった。そ
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
セミコロンレスJavaの構造化＆オブジェクト指向 - プログラマーの脳みそ
昨日、Java 7th moon 富山が開催されました。参加者21名と小規模ながら、会場は非常に盛り上がりました。ああ、凄く楽しい。こんなに楽しいのは久しぶりだ。スピーカーをしてくださった皆さん、参加してくださった皆さん、本当にありがとうございます！ LT(ライトニングトーク)で昔のネタを引っ張り出してSemicolonless Javaをやったのだけど、LTなので時間もなく一番アツイ部分が伝えられなかったのでちょっと書いておこう。 歴史 Semicolonless Java(セミコロンレスJava)はJavaのサブセットで、Java言語からただひとつセミコロンを取り除いただけのプログラム言語だ。 この言語自体は1996年にJavaがリリースされたと同時に実装が存在したが、誰にも知られていなかった。この言語が発見されたのは2010/3/21で場所は熱海。java-ja温泉というイベントの2
プログラミング用フォント Ricty
お知らせ Ricty および Ricty Diminished は、2010 年代前半には欧文・和文合成プログラミング用フォントとして先駆的でしたが、現在は前時代的な存在となっています。不具合もいくつか確認されています。良質なプログラミング用フォントが数多く登場していますので、それらの利用をおすすめします。 序文 Ricty（リクティ）は Linux 環境での研究・開発を想定したプログラミング用フォントです。テキストエディタやターミナルエミュレータ、プログラミング言語やマークアップ言語に対する使用に適しています。Inconsolata と Migu 1M の合成、および、プログラミング用フォントとしてのいくつかのチューニングを行う生成スクリプトを配布しています。Inconsolata 作者の Raph Levien 氏、Migu 1M 作者の itouhiro 氏、M+ M Type-1
業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
Brainf*ck
アラン・チューリングという計算機科学者の考えた、 「チューリング・マシン」という仮想の計算機があります。 これは [０を書く]、[１を書く]、[右に進む]、[左に進む] と言った 非常に簡単な命令のみを実行できる想像上の計算機ですが、 我々の使っているパソコンでできるような計算は全て、 チューリングマシン用のプログラムとして書ける、ということが知られています。 …という前置きを付けてなんだか重々しい言語に見えてきたところで(^^;、 たぶんご存じの方も多いと思われる、わずか８文字の組み合わせで ありとあらゆるプログラムを表現する Brainfuck を弄ってみるとしましょう。 * Hello, World 導入 サンプル：表示１ サンプル：表示２ サンプル：echo * サンプル：足し算 サンプル：掛け算 C++によるインタプリタ実装 * サンプル：条件分岐１ サンプル：条件分岐２ まとめ
Googleが開発したJavaデバッグを簡単にする新技術「cofoja」 | エンタープライズ | マイコミジャーナル
Java Programming Language Googleの20%プロジェクトからJava向けの新しい技術「cofoja (Contracts for Java)」が公開された。既存の実装に大きく手を加えることなく、デバッグをより簡単にしてくれる効果が期待できる。バグは些細なコードが起こすものだったりするが、それを追跡して発見するのは時に困難を極める。これは問題が発生した箇所と、実際にバグがある箇所が大きく離れていることが理由になっていることもある。問題発生箇所とバグ発生箇所を近くにまとめることができれば、それだけバグ発見も取り組みやすくなる。 cofojaはこれを簡単に実現するための技術。インタフェースに制約表現を追加可能にするところがポイントとなっており、クラスの実装に手を加えなくてもインタフェースに制約表記を追加することで実行時にチェックできるようになる。ブログに掲載されている
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog
どうしてプログラマに・・・プログラムが書けないのか?を読んでいて出てきたので出展の一つを訳してみた。Separating Programming Sheep from Non-Programming Goatsの和訳。 プログラミングというものには向き不向きが強く出るということはわりと知られていると思うが、このエントリではプログラミングができるかできないかは比較的簡単なテストによって、プログラミングの訓練を始める前の段階で分かると主張している。どうしてプログラマに・・・プログラムが書けないのか?では、そもそもこの事前テストをパスしていないような人達までプログラマとして応募してくると言っており、その判定法として有名なFizzBuzz問題を挙げている。 追記（2019/2/28) 注意： なおこの論文はしばらく前に著者の一人によって撤回されたようです Camels and humps: a r
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
名前可逆性 - Strategic Choice
名前可逆性*1どういうこと？名前は、その元となった説明文を復元できなければならない。どうすれば？「ループバックチェック」を行います。説明文から名前を考えたら、今度は逆に名前から推測できる説明文を考えます。説明→名前→説明の順で、一周回って元に戻る（ループバックする）ように説明が一致すれば良し、一致しなければ要注意となります。たとえば？説明文：音声を使ってHogeシステムを操作する機能 × 音声認識機能音声を認識して、それで「操作する」という部分が伝わらない。「音声でデータを入力する」と受け取られかねない。 △ 音声操作機能この場合、「音声によって操作する」ではなく、「音声を操作する」と受け取られかねない。説明文にある単語をそのまま使えばいい、というわけでもない。 △ 音声コントロール機能コントロールには「コピーコントロール」のような使い方もある。よって、「音声によって操作する」ではなく、「
変数名補足 - いいプログラムを書こう
変数名についての補足情報 - 変数名の力 スコープと変数名 スコープとは、その変数が見える範囲のことをさします。たとえば、 foo () { int i; ... if (i == 0) { int l; ... } } この場合、iのスコープはfoo()の中全体、lのスコープはifの中となります。 さて、本題に戻りますが… 短い変数名は悪者か？ いいえ。 短い変数名が示すことは、自分が一時的な(スコープが狭い)変数だということです。 より長い名前は、まれにしか使用されない変数やグローバル変数に適し、短い名前は、ローカル変数やループ変数に適します。 しかし、短くても意味を表しているほうが望ましいことは言うまでもありません。 計算結果を格納する変数の名前 total, average, maximum,...などの計算結果を入れておく変数名
勉強が出来ない奴はプログラマになれ！（バカだからできる勉強法） - IT戦記
どのくらいの人がこのブログを読んでいるか分かりませんが、 もし、勉強が出来ない人が周りにいたら、このブログを紹介してあげてください。 ふと 勉強が出来ない人は、プログラマになったほうがいいと思った。 僕はというと 自分でも驚くくらい勉強というものが出来ない。ものごとを知らない。 はっきり言ってバカなのである。 たとえば、 大学行ってない。 株式公開と上場の違いを知らなくて、一同ぽかーん。 つい最近まで、サイバーエージェントを知らなかった。（技術者には必要ない） 英語が一切読めない。 宮崎料理「冷や汁」を「冷や飯」だと思ってた。 基本的に会議とかでよく出る英語、「さじぇっしょん」とか、「あさいん」とか、「ぶらんでぃんぐ」とか、「うぇぶつーぽいんとおー」とか、よく分からん。 人力（じんりき）検索を入力（にゅうりょく）検索だと思っていた たぶん、まだまだあるけど、自分がバカだから気がつかないんだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
Dart programming language
