既存のプログラミング学習方法とガルこれの比較
programing.md 既存のプログラミング学習方法とガルこれの比較 | 動画 | セミナー | 書籍 | 仕事としてやる | ガルこれ --- | --- | --- | --- | --- | --- とっつきやすさ | ○ | × | × | ○ | △ 最初の一行を書くまでの敷居が低いか | △ | ○ *1 | × | ○ | ○ 文法や基本的な関数の習得に向いているか | × *2 | ○ | × | ○ | ○ モチベーションを保ちやすいか | △ | ○ | × | ○ | ○ プログラミング以外のことを学べるか （デザイン、ディレクション、マネジメント、テストの仕方、ライブラリのこと、などなど） | △ | ○ | ○ | ○ | × お金がかからない | ○ | × | △ | ○ *3 | ○ *1: 誰かが手取り足取り教えてくれるので *2: 基本文法は何度も書
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
Windowsのディレクトリ構成ガイドライン - torutkのブログ
Windows Vista/7 になって、ユーザーのディレクトリがC:\Users下になったり、C:\Users\<ユーザー名>\AddDataなるディレクトリが出来たり、C:\ProgramDataなるディレクトリが出来たり、といろいろな変化があります。 また、C:\Program Filesの下にインストールしたプログラムの設定ファイルを変更すると、C:\Users\<ユーザー名>\AppData\Local\VirtualStore\Program Files\foo\foo.ini などに書かれたりします。 そのような状況で、開発したプログラムをどこにインストールするように設定すればいいのか、Windowsの流儀が分からず、調べてみると、"Namespace Usage Guidelines for the Window Vista File System"という技術文書に行き当た
Shibu's Diary: ソフトウェアの世界は螺旋を周りながら進歩している
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。 うんこれ。2年ぐらい前にnode.jsで開発していた時にも、node.jsのnpmのエコシステムいつか破綻するよなぁって思ってた。で、去年cURL as DSL作ったんだよね。Rubyのコード生成はまだないけどね。 https://t.co/1C0yw0KPib — 渋川よしき (@shibu_jp) March 6, 2016 上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。 SourceForgeや
依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
目が見えなくてもプログラミングできるよ - Qiita
はじめに こんにちは！@moutendです。私は視覚障害があるので、普段は画面を見ずにMacのVoiceOverというスクリーンリーダーの音声のフィードバックを頼りにプログラミングをしています。ところで最近@ssotoyaさんの記事にて音声を頼りにプログラミングする様子が公開されました。スクリーンリーダーの音声を聞いたことがありますか？ - ラック公式ブログ - 株式会社ラック@ssotoyaさんは全盲のため全く目が見えないのですが、超高速でコーディングをされています。控えめに言って最高にロックです。私も負けていられません。ということで、この記事に触発されて、私も画面を全く見ずに音声のフィードバックのみを頼りにプログラミングしている様子をキャプチャしましたので公開してみます。具体的には、QuickTimeのスクリーンキャプチャ機能を使って画面を撮影しつつ、音声はsoundflowerという
ズンドコキヨシまとめ - Qiita
概要 いま、ズンドコブームが来てます。 Javaの講義、試験が「自作関数を作り記述しなさい」って問題だったから 「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数作ったら満点で単位貰ってた — てくも (@kumiromilk) March 9, 2016 非常にセンスが良いですね！ 巷では「ズンドコキヨシ」「キヨシチェック」「ズンドコチェック」などと呼ばれているようです。 さまざまなズンドコキヨシ プログラミング言語系 ズンドコキヨシ with Ruby by @yancya 無限に'ズン'と'ドコ'をランダムに返すEnumeratorを使ってるのがいいですね ワンライナーズンドコキヨシ with Ruby by @from_kyushu 毎回 'ズン'と'ドコ'のランダムな5つの組み合わせを
難しいことを簡単に学ぶ方法 ― 強力なスキルを新たに身に着けるための3つのステップ | POSTD
ここ数年、私はWeb開発と機械学習の自習に多くの時間を割いてきました。 学習のテーマは、Javascript、Node、ReactからPython、scikit-learn、ニューラルネットワークに至るまで多岐にわたりましたが、全てに対して私は一貫したアプローチで取り組みました。 そのアプローチとは、単純な（陳腐と言ってもいい）3ステップで進める、という手法です。しかし、 Web開発のシロウトだった私が5カ月で、プロだと自覚できるほどになった のはひとえに、このアプローチで臨んだ自習の成果だと思っています。 そこで私は、この自習法がほかの誰かのお役に立てるかもしれないと思い、少し記事を書いてみることにしました。 この記事は、何も分からないままやみくもに挑戦を始めた、2012年当時の自分自身に教えるつもりで書いています。 ステップ1：習うより慣れろ 新しいテクノロジを学ぶためにまず実行する最
PuzzleScript - an open-source HTML5 puzzle game engine
PuzzleScript! PuzzleScript is an open-source HTML5 puzzle game engine. Make A Game First Steps Gallery
ファミコン風パズルゲーム開発が可能なHTML5エディタ「PuzzleScript」の言語仕様がマニアック過ぎる件！ : うえぶはっく
ブラウザ上で、プログラミングからステージの構成・実行・公開まで可能な、統合型パズルゲーム開発エディタ「PuzzleScript」のご紹介！ すべて無料で使えるので、今すぐパズルゲームを作りたい！という人には最適なのですが、特徴的なのはプログラミングに使う言語…。 独自の仕様で作られた言語のようで、最初はよく分からず…かなりマニアック感が漂っていたのですが、分かってくると実はスゴイ仕様なのでは？と感じるようになりました。 と言うのも、簡単なゲームロジックならたった1行で書けてしまうのですから。。 使い方！ まずは、簡単なサンプルを見ながら、「PuzzleScript」の使い方に触れていこうと思います。 最初に、トップページにある「Make A Game」ボタンをクリックしましょう！
PHPの生みの親、ラスマス・ラードフ氏インタビュー | gihyo.jp
PHPの生みの親、ラスマス・ラードフ氏インタビュー 2015年12月に無事公開されたPHP7。その公開に先立ってPHPの生みの親であるラスマス・ラードフ氏に話を伺う機会がありました。英語で行われた一時間のインタビューは長大ですがラスマス氏の思想がよく分かる話題が多く、可能な限りそのままの形でお伝えすべく、その模様すべてをお届けします。 なお、インタビューは10月に開催されたPHPカンファレンス2015の講演終了後に行われ、リリースに関する話題などはその時点でのものです。 現在の仕事と生い立ち ―――― まずは、PHPを作ってくださってありがとうございます。今日の基調講演もすばらしかったです。 ラスマス：ありがとうございます。 ―――― いきなりですが、個人的な質問から始めてもいいでしょうか。 ラスマス：どうぞ。 ―――― Etsyではどのようなお仕事をなさっているんですか？ ラスマ
Martin Fowler's Bliki in Japanese - プレゼンテーションとドメインの分離
http://martinfowler.com/bliki/PresentationDomainSeparation.html 最も有用な設計原則に、 プログラムのプレゼンテーション層（ユーザーインターフェイス）とその他の機能をうまく分ける、というのがあります。 私はこれを発見して以来、ずっと慣行しています。 長い間これを使ってきて、いくつものメリットを発見しました。 プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる（選択可能なプレゼンテーション部分で見かける） プレゼンテーション部分のコー
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
本当に有意義なエラーメッセージを書くには | POSTD
想像してください。あなたは今、オフィスにいます。周りとは仕切られた個別スペースです。今週は、近々新たに展開する予定の製品を紹介するために多くの時間を割いてきました。疲れが溜まり、不機嫌ぎみになっています。今はようやく近づいた週末が待ち遠しくて仕方ありません。 しかしその前に、新製品を紹介するホームページがWindows 10で正常に動かくかどうかを試してみなければなりません。あなたは問題ないはずだと信じています。あなたが信頼を寄せているMacには、Windowsを問題なく実行できるソフトもインストールされています。 ソフトを起動してみると、丁寧にもWindowsがポップアップ通知で可能なアップデートがあることを知らせてくれます。もちろんアップデートを開始するため、あなたは了承します。 すると、こんなものを目にするのです。 訳：何かが発生しました。 何かが発生。 新製品の準備のため期限が迫っ
学校教育とプログラミングは相性が悪い そして適性とかの話 - タオルケット体操
最近はあまり話題にのぼらない気もしていますが、何かと動きの遅い我が国でもプログラミング必修化の流れはちゃくちゃくと進んでいるような感じを感じます。 プログラミングの義務化についての問題点は、カリキュラムや、適切なスキルをもった教師の明らかな不足など色々と挙げられていますが、今回はそれとは別な、そもそも的な論を展開したいなぁとかそういう感じです。ちょっと長いです。 決して、僕が学校が嫌いだったからとりあえず批判しておきたいとかそういうことではないです。 減点方式 学校教育が減点方式であること自体の是非はここでは述べない。 とりあえず、採点をしやすくするという目的を達成するためには悪くない方式だとは思っていますよ。何のための採点か、という理想が欠けているのが問題になっているのだとは思うけども。 エジソンの 「失敗なんかしていない。うまくいかない方法を一万通り発見しただけだ」 なんていう結構有名
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
厚切りジェイソン、NHKでプログラミング番組「可能性は無限大」
GUIアーキテクチャパターンの基礎からMVVMパターンへ
http://kwatch.houkagoteatime.net/blog/2015/08/30/why-is-functional-lang-so-hard/