タグ

programmingに関するmyokoymのブックマーク (16)

  • プログラミング用フォント Ricty

    お知らせ Ricty および Ricty Diminished は、2010 年代前半には欧文・和文合成プログラミング用フォントとして先駆的でしたが、現在は前時代的な存在となっています。不具合もいくつか確認されています。良質なプログラミング用フォントが数多く登場していますので、それらの利用をおすすめします。 序文 Ricty(リクティ)は Linux 環境での研究・開発を想定したプログラミング用フォントです。テキストエディタやターミナルエミュレータ、プログラミング言語やマークアップ言語に対する使用に適しています。Inconsolata と Migu 1M の合成、および、プログラミング用フォントとしてのいくつかのチューニングを行う生成スクリプトを配布しています。Inconsolata 作者の Raph Levien 氏、Migu 1M 作者の itouhiro 氏、M+ M Type-1

  • Route 477 - UXを重視したプログラミング言語

    ■ [ruby] UXを重視したプログラミング言語 Rubyが生まれたのは今から20年前のことだ。Rubyの肩書きは「オブジェクト指向スクリプト言語」であるが、実のところRubyにしかない特徴的な機能というものは特になく、いろんな言語から良いところを寄せ集めてきたというのはまつもとさんも各所で書かれている通りだ。 その代わり、Rubyはプログラムの書きやすさを常に念頭に置いてデザインされてきた。 それはプログラミング時の脳の負担を最小にする、と表現されることもあるし、楽しくプログラミングできる、のように表現されることもある。 人によっては、プログラミング言語にとって構文は質的ではない、という向きもあるだろう。それに対して、 構文やメソッド名を工夫することはプログラミング言語の使用感に結構な影響を与えるし、「触りごこちの良さ」は重要なことである、というのがRubyの思想である。 最近、UI

    Route 477 - UXを重視したプログラミング言語
  • Inversion of Control コンテナと Dependency Injection パターン

    以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 記事では、このパタ

  • 第2回 コーディングスタイルについて | gihyo.jp

    コーディングスタイル 「プログラミングに関する雑多な事柄」がテーマの連載、第2回の今回は「コーディングスタイル」について取り上げたいと思います。 コーディングスタイルは、コードの書き方に関するスタイルです。インデントのしかたや、変数名・関数名の表記法などはコーディングスタイルで扱われる要素の代表例です。 コーディングスタイルが異なると、同じ意味のプログラムでも見た目はだいぶ変わります[1]⁠。 ●『プログラミング言語C』(⁠通称K&R)のスタイル for (i = 0; i ●GNUプロジェクトのスタイル for (i = 0; i スタイルの一貫性 スタイルをごちゃまぜにするとコードが非常に読みづらくなるため、1つのプロジェクトの中ではコーディングスタイルの一貫性を守ることが重要です。 スタイルにも個人の趣味というものがありますが、個人の趣味よりもプロジェクト内での一貫性のほうが重要で

    第2回 コーディングスタイルについて | gihyo.jp
    myokoym
    myokoym 2012/11/11
    "生産性の高いプログラマはコードだけでなく,議論を早く片づけることも得意"
  • クリアなコードの作り方: オーバースペックな機能を使わない - 2012-11-01 - ククログ

    当は「…ない」と否定形ではなく「…する」というような肯定形のタイトルにしたかったのですが、すっきりしたタイトルが浮かびませんでした。肯定形で書くと「身の丈にあった機能を使う」です。 このタイトルは、書いている人にとってオーバースペックかどうかではなく、書いているコードにとってオーバースペックかどうかという意味です。初心者だからメタプログラミングはするな、という話ではありません1。やり方をいくつも知っていると、より汎用的なやり方を選択したくなるでしょうが、汎用的かどうかという基準だけで考えるのではなく、そのコードにあったやり方かどうかという基準でも考えましょうという話です。 コードを読む側を経験するとわかりますが、コードを書いた人がどうしてこのようなコードを書いたかを知っているか知っていないかでコードの読みやすさが違います。もちろん、どうして書いたかを知っている方が読みやすいです。例えると

    クリアなコードの作り方: オーバースペックな機能を使わない - 2012-11-01 - ククログ
    myokoym
    myokoym 2012/11/11
    リーダブルコード一冊分の価値がある記事
  • DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ

    先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの?」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob

    DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ
  • やっぱ、仕事でJavaやる人はEffective Javaは読んでおくべきだと思うよ。 - sawatの日記

    めずらしく仕事の話なのですが、なんか年明けから他部署に出稼ぎに行かされています。で、その仕事の内容というのが「別の誰かがつくった膨大なJavaソースにJavadocを書き込む」という訳の分からないことをやらされています。しかも、そのJavadocというのが普通のクラスやメソッドの外部仕様について書くのではなくて、完全な内部仕様でほとんどソースの和訳みたいなのを書かなきゃいけないという・・・。年頭からいったいどうやってやる気を奮い立たせればいいのか分からなくなってきます。まったく。 まあ、とにかくソースを読んでがんばってJavadocを書いてるわけなのですが、人のコードを見るとどうもアラに目がいってしまいエントリのタイトルの通りに思うわけですよ。ハラに溜めておくのは精神衛生上よくないと思うので、気づいたのをここに列挙してみます。 列挙する nullでないことが確定されている変数をnullチェ

    やっぱ、仕事でJavaやる人はEffective Javaは読んでおくべきだと思うよ。 - sawatの日記
  • WEB+DB PRESS vol.63 特集1の「第2章:テスト編」を執筆させていただきました - t-wada の日記(旧)

    WEB+DB PRESS vol.63の特集1「現場で役立つ実践ノウハウWeb開発の「べし」「べからず」〜危険なコード,腐るテスト,不安定なインフラからの脱却〜」の第2章、 "テスト編 腐らないテストコードにするための「書き方」と「動かし方」" を執筆させていただきました。 WEB+DB PRESS Vol.63 作者: 竹迫良範,和田卓人,おにたま,中島聡,角田直行,はまちや2,上谷隆宏,青木俊介,大塚知洋,生尾剛士,大和田純,永安悟史,馬場俊彰,久保達彦,白土慧,じゅんいち☆かとう,太田昌吾,小野修司,ミック,嶋田裕二,個々一番,みやけん,清水亮,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2011/06/24メディア: 大型購入: 20人 クリック: 434回この商品を含むブログ (22件) を見る WEB+DB PRESS に書くのは vol.49 の

    WEB+DB PRESS vol.63 特集1の「第2章:テスト編」を執筆させていただきました - t-wada の日記(旧)
    myokoym
    myokoym 2011/06/25
    「さまざまな現場で出会うであろうテストコードのべし、べからず」「WEB+DB PRESS の Twitter 公式ハッシュタグは #wdpress 」
  • DIコンテナ【Dependency Injection Container】

    DIコンテナは,「DI(Dependency Injection:依存性の注入)」と呼ぶデザインパターンに基づいて作られたコンポーネント群を集中管理するためのソフトウエアです。 DIは,コンポーネント(クラス)間の依存関係をソースコードから取り除くことで,プログラムの実行時までコンポーネント同士が依存関係を持たないようにするデザインパターンです。 例えば,あるクラスAの中で別のクラスBのインスタンスを生成して利用しているとき,AはBに強く依存してしまっています。つまり,Bを別のクラスに差し替えたときなどにはAも変更しなければなりません。このような依存関係は,AとBを別の人が作っている場合などに特に困ります。 こうした依存性をクラスから取り除くのがDIパターンです。Bへの依存性をAから排除するには,まずBの機能を抽象化したインタフェースIを定義し,Iを実装したクラスとしてBを作ります。 Bの

    DIコンテナ【Dependency Injection Container】
  • http://japan.internet.com/column/developer/20080926/26.html

  • プログラミング勝負! Google Code Jam 2011

    .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

    プログラミング勝負! Google Code Jam 2011
  • vim で実践! コードリファクタリング

    どうも、技術部でプログラマをしている鈴木です。シャノンに来てからは主に Shanon Marketing Platform の国際化対応をやっています。 わたくし、いわゆるひとつの vi 使いでして、世の vi 使いの類にもれず、世の中のすべてのアプリケーションの UI が vi ライクになればいいと常日頃思っているクチなのですが、(この記事も、vi で書いてからコピペであります。WYSIWYG なんてクソくらえ! でありますw)今日は恥ずかしながら、そんなわたくしが普段どんな感じで vi を使っているかをお見せしたいと思います。

    vim で実践! コードリファクタリング
  • Sapporo.jsでJavaScriptの成り立ちについてLTしてきました。 - I am bad at math

    当初はNodeのことを5分で話すつもりでしたが、id:tricknotesの「時間はどのくらいあればいいですか?」という有難い申し出を受けて設定したのが20分。 さすがに手元の資料では足りないのでJavaScript歴史についても話してきました。 そちらについては資料すら作ってなかったのでホワイトボード使いつつ記憶を頼りに延々しゃべっていくという・・・さらに字が汚くて見えづらかったと思います。すみません。 JS history View more presentations from badatmath で、帰ってきてからざざざっと資料を作りました。 まずはECMAのトコまで。 JSってサイドストーリーがとっても多い言語なので突っ込んで調べるといろいろ新しい発見があり、ネタに事欠かない言語でもあります。そういうのを調べて行くとかなりJavaScriptに親近感が湧くようになるのでみなさん

    Sapporo.jsでJavaScriptの成り立ちについてLTしてきました。 - I am bad at math
  • ウノウラボ by Zynga Japan: 家庭用ゲームのプログラマーがSNSゲームのプログラマーに転職するために必要なもの

    こんぬつは&はじめまして。 12月に入社したサカモトです。 私は元々SONYとかNintendo機向けの家庭用のゲーム開発を生業にしてきましたが、ついこの前からSNSアプリの開発をしています。 私と同じように、家庭用ゲーム機のプログラマーからSNSゲームプログラマーに転身したいと考えている方のお役に立てればと思い、私の経験を元に '転職するために必要なもの' のお話をさせていただきたいと思います。 採用されるために必要なもの ご自身で事業を始める場合には必要の無い事ですが、どこぞの会社さんに所属したいとなるとまず雇って頂くほかありません。そこで、採用されるために必要とされるスキルや経験を挙げてみたいと思います。 身近なところで弊社ZyngaJapanのエンジニアの採用ページを見てみると「必須スキル・経験」として以下のような事が書いてあります。 3年以上のプログラミング業務経験 また

  • ニンテンドーDSi上でプログラム言語「BASIC(ベーシック)」が使える「プチコン」

    キャラクター画像作成ツール、背景用マップエディター、グラフィックツール、ゲーム3種類、機能サンプルプログラム7種類など13種のプログラムに加えてグラフィックやBGMに豊富なプリセットデータを用意し、ユーザー自身によるプログラムの改造や機能の追加も直接可能、作成したプログラムやデータは通信機能を使って周囲のユーザーに送信できるというかなりすさまじいニンテンドーDSiウェア「プチコン」が2011年3月9日より「DSiショップ」にて新発売されるそうです。 実際の動作画面や詳細な情報は以下から。 プチコン http://smileboom.com/special/petitcom/ 見ての通りのBASIC。「プチコンが採用しているSMILEBASICはオブジェクト指向もコンパイル型もGUIもこれっぽっちも気にかけていません」とのことで、思いつきでいきなりプログラムを打って「RUN」するだけで実行可

    ニンテンドーDSi上でプログラム言語「BASIC(ベーシック)」が使える「プチコン」
    myokoym
    myokoym 2011/02/24
    No, VB Gen.
  • プロセス、スレッド、ファイバ、タスク、ジョブ、違いを整理してみよう - Schi Heil と叫ぶために

    まずは分かりやすいプロセスとスレッドから。 WindowsLinux などの汎用 OS 上のアプリケーションは一般にプロセスとして動作している。プロセスはプログラムの実行単位である。プロセスは1つ以上のスレッドと、ファイル、ヒープメモリなどのリソースで構成される。一方、スレッドは CPU 利用の単位である。スレッドはそれぞれが専用のスタックと CPU レジスタのコピーを保持するが、ファイルやヒープメモリは同一プロセス内の全てのスレッドで共有する。 スレッドのさらにサブセットがファイバである。スレッドとの違いは切り替え動作にありファイバのほうが軽いというメリットがある。プロセス、スレッド、ファイバの関係はこちらの説明が分かりやすかった。 プロセスはプログラム実行のための固有のメモリ空間を持っており、最も独立性の高い実行単位である反面、起動や切り替えに時間がかかるという特性を持っています

    プロセス、スレッド、ファイバ、タスク、ジョブ、違いを整理してみよう - Schi Heil と叫ぶために
  • 1