すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
インターフェイスを設計するために読んだ技術書まとめ - 自由課題
アーキテクトの(機能面での)主要な仕事の１つに、システムを構成するサブシステム/コンポーネントの境界、つまりインターフェイスを決める、というものがあります。またはそこまで大げさに捉えなくても、例えばライブラリのAPIを設計する、というのは単にプログラミングをする、ということとは少し違う視点が求められるように思います。 案外インターフェイスを考えるという観点での技術書まとめがないような気がしたので、需要があるかわかりませんが関連して読んだ本を紹介しておきます。なお、個人的なキャリア上、C++/Javaが対象です。(色々経験したら随時追加するかも知れません) 何か他にいい本があったらぜひ教えてください。 言語仕様をきちんと知る まずはAPIを設計する対象言語をよく知る、ということは必要であると思います。これだけだと、結果的にプログラミングに精通するということとあまり変わりはないかも知れません。
ライブラリを作る事でプログラミングスキルは本当に向上するのか。
Miki Ishijima デザインワーク、ソフトウェア開発のワークフロー、デザイン自体の考え方に関する著書を持つ。2013年にザ・マーズナレッジ株式会社設立。 works ライブラリを作る事でプログラミングスキルは本当に向上するのか。 Posted by Miki Ishijima on July 24, 2014. デザイナーのわたしがプログラムの基礎をだいたい3日で覚えた1つの方法で、Minecraftとプラグインを使ってのプログラミングの楽しさについて書きました。 あれから、いまだに飽きもせず休みの日などにコードを書いています。 まだまだ微妙なこともあるのですが、いくつかプログラムを作ってみて良く使う機能をライブラリにしておきたいなと思ったので作ってみました。 woopsdez/ComputerCraft 他の人にも使ってもらえるといいな。 ライブラリ作成の実際の流れ いきなり作る
Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで
Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで 馬場俊彰 マイナビ出版 2,948円 (2,680円+税) Webサービスを高速化し、可用性を高めるスキルを身につける！ Webエンジニアの仕事の幅を広げるためのインフラの知識をピックアップしてまとめました。インフラまわりの技術の基本から、インフラ基盤の手配の方法、設計のセオリー、システム監視、チューニングまで、ツボを押さえてまとめています。 関連サイト本書の関連ページが用意されています。 Webエンジニアが知っておきたいインフラの基本｜マイナビブックス内容紹介本書は、Webアプリケーションエンジニアや、フロントエンドエンジニアを対象に、知っておくと便利なインフラの知識をまとめた本です。 担当しているWebサービスをもっと高速化させたい方や、バックエンドと最適化された無駄のないアプリケーションを
そのオブジェクト指向入門は間違っている（大げさ） - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日！ - uzullaがブログ
はい、Webアプリエンジニア養成読本 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう！」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読本アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です！ Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz
Makeについて知っておくべき7つのこと | POSTD
Make は、様々なタイプのファイルのビルド作業を自動的に行ってくれるシンプルかつ強力なツールです。しかしながら、makefileを書く際に問題にぶち当たるプログラマもいれば、Makeの基本知識がないことで、既存のものを再発明してしまうプログラマもいます。 Makeの働き デフォルトでは、Makeは一番目のターゲットから開始します。このターゲットのことをデフォルトゴールと呼びます。 Makeはカレントディレクトリのmakefileを読み込み、一番初めのルールで処理を開始します。しかし、Makeが完全にこのルールを処理する前に、ルールが依存するファイルのためのルールを処理しなければなりません。各ファイルそれぞれは、自身のルールに従って処理されます。 実はこれは、各ターゲットの再帰的アルゴリズムになっています。 ターゲットをビルドするルールを見つける。ルールがないようであれば、Makeはうまく
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
社会人10年目から始める競技プログラミングのすすめ - kuuso1のブログ
これは、Competitive Programming Advent Calendar 2014の17日目の記事です。 競技プログラミングという世界を知って1年がたちました。結構飽きやすい性格の自分が1年ほどコンスタントに参加するという充実したプロコン（プログラミングコンテスト）ライフを送ることができた記念に、これからプロコンに参加してみようという方向けの記事を書かせていただきます。CPAC2014参加諸氏のような技術的に高度な内容は残念ながらなさそうですが（書けるものなら書きたい）、10年目エンジニア的視点で自分が感じたことを踏まえて「これはいいものだ」と思えたところなどを中心に振り返ることで、なんとかタイトル詐欺を回避したいと思います。中盤はお目汚し感が強いかも。。 経緯や参加したプロコンなど 半導体関連のメーカーで開発の仕事に従事していますが、2012年に職場都合で富山県に引っ越すこ
競技プログラミング特有の変な実装テク - ichyo.jp
初めに この記事はCompetitive Programming Advent Calendar 2014の15日目の記事です． 競技プログラミングでは，アルゴリズムをひらめく力や，数学やアルゴリズムの知識量などが強さを決める大きな要素ではありますが， もちろん，プログラミングを使った競技である以上は，コードの実装力が勝敗を分けることもあります． 例えば，ICPC系のコンテストでは，アルゴリズムを考える能力よりも，実装量の多いプログラムをいかにバグなく高速に実装するかが重要な 問題セットが与えられることが時々あります． 競技プログラミングと無縁なプログラマーは，実装力と聞くと， クラスの構造をうまく設計したり，変更に強い美しいコードを実装する能力だと想像する人がいるかもしれません． ですが，プログラミングコンテストに必要な実装力は，そうした保守性や拡張性ではなく， 「目的の処理をシンプルな
C言語で可変長引数をとる関数を、型安全に書く方法
C言語の可変長引数は、型安全でない（まちがった型の引数を渡してもコンパイルエラーにならない）とされています。これは言語仕様の理解としては正しいのですが、特定の型の引数を任意の個数とる関数に限っては、マクロを使うことで型安全性を確保することができます。 任意の個数のdoubleを引数にとり、その和を返す関数「sumf」を例にあげて説明します。 C言語の可変長引数機構を使ってsumfを定義すると、以下のようになります。 #include <math.h> #include <stdarg.h> #include <stdio.h> static double sumf(double nfirst, ...) { double r = 0, n; va_list args; va_start(args, nfirst); for (n = nfirst; ! isnan(n); n = va_a
人工知能が急に進化し始めた！ | TheWave
人工知能。何十年も前からある言葉だ。国家プロジェクトとして研究されていた時期もあった。それでも完成しなかった。やはり人間の脳は複雑で、それをコンピューターで真似することなど不可能かもしれない。 人工知能。何十年も前からある言葉だ。国家プロジェクトとして研究されていた時期もあった。それでも完成しなかった。やはり人間の脳は複雑で、それをコンピューターで真似することなど不可能かもしれない。 「ところがブレークスルーが起こったんです」と東京大学の松尾豊准教授は熱く語る。 ▶2012年。人工知能研究に火がついた 2012年。人工知能の精度を競う国際的な大会で、カナダのトロント大学がぶっち切りの勝利を収めた。それも１つの大会だけではなく、３つ続けてだ。 「優勝したのは、画像認識、化合物の活性予測、音声認識など３つのコンペティション。まったく異なる領域にも関わらず、今までその分野を専門的に研究していた人
iOSと機械学習 - その後のその後
ビッグデータとかの機械学習隆盛の背景にある文脈や、その拠り所となるコンピュータの処理性能から考えても「モバイルデバイス向けOSと機械学習を紐付けて考えようとする」ことはそもそもあまり筋がよろしくない・・・とは思うのですが、やはり長くiOSだけにコミットしてきた身としては、新たに興味を持っている機械学習という分野と、勝手知ったるiOSという分野の交差点はないのかなと考えずにはいられないわけでして。。 そんなわけで、「iOS と機械学習」について雑多な切り口から調べてみました。 iOSで使える機械学習ライブラリ DeepBeliefSDK コンボリューショナルニューラルネットワークを用いた画像認識ライブラリ。iOSとかのモバイルデバイスで処理できるよう、高度に最適化してある、OpenCVと一緒に使うのも簡単、とのこと。 https://github.com/jetpacapp/DeepBeli
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
名著『リーダブルコード』を解説者と一緒に読み解こう 〜3章 誤解されない名前〜｜オンライン動画授業・講座のSchoo（スクー）
■ リーダブルコード入門 プログラム経験のある方が、リーダブルコード(※1)を書くために必要な考え方を学ぶ事ができます。 今回は、名著「リーダブルコード」の解説者である須藤先生と一緒に「3章 誤解されない名前」を読みながら、よい名前のつけ方について学びます。 ■ 対象者 プログラミング経験者で、リーダブルコードを書きたい方 変数や関数の命名に自信が持てない方 自分のコードを他の人にとっても読みやすいコードにしたい方 ■ 関数や変数で『誤解されない名前』を付けられるようになろう プログラミングを行うと、変数や関数に名前付けする機会が沢山あります。 でも名前のつけ方って、まわりの人に聞いてもなかなか明確な答えを教えてもらえませんよね？ 「うーん、自分も難しいなぁと思っているんだよねぇ」 「ケースバイケースだからなぁ」 「今回はA案の方がいいかなぁ」 でも、ベースとなる考えを持っていれば、よい名
if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか？ @ajiyoshi.gist
gistfile1.md if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか？ @ajiyoshi.gist twitterからながれてきたこの話題。昔のCコンパイラは、if文の条件節で代入を書いても文句を言わなかったので、このようなコードに何の警告も出なかった。 #include<stdio.h> int main() { int x = 0; /* おそらく意図と違う。 x == 1 と書くべきであった これでは常に実行されてしまう */ if ( x = 1 ) { puts("残念"); } } 「これをこのように書けば、コンパイルエラーになり、ある種の誤りをコンパイラに見つけさせることができる」というのが、「老害」とされる人の主張である。 /* これはコンパイルエラーになる */ if ( 1 = x ) { puts("残念"); } もし使っている環境が「コンパ
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
MSが「Visual Studio Community」を無償で提供するワケ
米マイクロソフトは2014年11月13日、統合開発環境「Visual Studio」の次期版「Visual Studio 2015」のプレビュー版を公開するとともに、無償版の新エディション「Visual Studio Community 2013」を発表、公開しました。いずれも、オープン化やクロスプラットフォーム化を推し進める同社の戦略を色濃く反映した製品となっていて、話題となっています。 個人開発者や中堅中小企業の開発者が特に期待しているのは、無償版の「Visual Studio Community」（以下、Community）でしょう。Visual Studioには、これまでも無償版の「Visual Studio Express」（以下、Express）がありましたが、Expressには機能的な制限がありました。一方、Communityは、従来の「Visual Studio Profe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/kenokabe/items/9c650ec8bcb1418c596d
開発効率アンチパターン
Site is undergoing maintenance