This domain may be for sale!
2011/02/09 ページ作成 2011/02/09 最終更新 クロノス・クラウン合資会社 柳井政和 HP:http://crocro.com/ Twitter:http://twitter.com/ruten はじめに このマンガは、私が「2011/01/16のSwapSkillsの勉強会」用に作成した「Androidで動く HTMLとJavaScriptで作る電子書籍アプリ」という資料が元ネタになっています。この資料から「Android開発環境構築」部分を抜き出して、16ページのマンガとして作成しました。切っ掛けは、窓の杜に「WebブラウザーからAndroid向け電子書籍を制作できるサービス“Androbook”」という記事を書いたことです。この記事を書く際に、「16ページのマンガが欲しい、それも『コミPo!』で」と提案されたので、技術資料のマンガ化に取り組みました。内容
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー All The Cheat Sheets That A Web Developer Needsという記事を先日見つけて,割と知らないものが多く,また便利だったのでご紹介:-)。英文のチートシートだけど,仕様を短くまとめてあるチートシートは日本人のWeb開発者も便利に使えるはず。 HTML HTML/XTML in one page HTML5: The Evolution of Web Standards by James Sugrue (X)HTML Elements and Attributes Doctype Declarations (DTDs) XHTML Character
Java Programming Language Googleの20%プロジェクトからJava向けの新しい技術「cofoja (Contracts for Java)」が公開された。既存の実装に大きく手を加えることなく、デバッグをより簡単にしてくれる効果が期待できる。バグは些細なコードが起こすものだったりするが、それを追跡して発見するのは時に困難を極める。これは問題が発生した箇所と、実際にバグがある箇所が大きく離れていることが理由になっていることもある。問題発生箇所とバグ発生箇所を近くにまとめることができれば、それだけバグ発見も取り組みやすくなる。 cofojaはこれを簡単に実現するための技術。インタフェースに制約表現を追加可能にするところがポイントとなっており、クラスの実装に手を加えなくてもインタフェースに制約表記を追加することで実行時にチェックできるようになる。ブログに掲載されている
先日公開されたPythonドキュメントの日本語訳のPDFがすごい。なにがすごいって、ページ数が合わせて3000ページぐらいあるところが。 ダウンロードファイル一覧 - Python Japanese Environment - OSDN いつもお世話になってます。ドキュメントの著者、翻訳者の方々に感謝。 追記 このPDFはSphinxというドキュメンテーションシステムを使って出力されてます。 オリジナルはreStructuredTextという形式のテキストファイルです。 Overview — Sphinx 1.4.3 documentation Sphinx-Users.jp — Python製ドキュメンテーションビルダー、Sphinxの日本ユーザ会 Google Project Hosting
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下: 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
WebサービスEvernoteEvernoteを挫折した人、僕ともう1度本気になって挑戦してみませんか?[環境作り編]2011年1月25日709 @JUNP_Nです。Evernoteを挫折した僕がもう1度本気になってEvernoteに挑戦してみる企画の第2弾。 第1弾がそこそこ評判がよかったみたいなので調子にのって続編です。今回はEvernotoを取り巻く環境を作り直してみたので紹介します。 前回の記事「Evernoteを挫折した人、僕ともう1度本気になって挑戦してみませんか?[運用ルール作り編]」ではEvernoteを自分に合った使い方をするために考え直して、ノートブック/スタックとタグの使い方に関してルールを決めてみました。 今回はどうやって情報をEvernoteに集約させるかについて考えてみます。 ※ちなみに前回の記事を投稿した後に有料アカウントを取得しました。 目次まずはiPhon
Androidアプリケーション開発コンテスト「Android Application Award (A3)2010-2011 Winter」のエントリー締切がいよいよ2月7日に迫った。開発者を応援するべく、ITproで掲載してきたAndroidアプリ開発ノウハウをまとめた。 あなたのAndroidアプリを“カメラアプリ化”する カメラアプリを作ろう 第1回 ボタン一つでアプリの背景をカメラ写真に変える 第2回 カメラ機能を加える Android ユーザビリティセミナー ユーザビリティ調査の極意を聞き、Flash/AIRによるAndroid開発の実際を見る AndroidアプリをJavaScriptやAIRで作る AndroidアプリをJavaScriptやAIRで作るツール 初めてのAndroidプログラミング Eclipseを導入して開発環境を整えよう 開発用PCとAndroid端末の実
こんにちは! スマートフォンアプリ開発チームのfaultierです! 得意な口説き文句は「君のprotocolにconformしたい」ですが、今のところ使ったことはありません。 みなさん、普段の開発ではエディタは何を使ってますか? きっとvimかemacsかメモ帳か念力による直接入力を使っていると思います。ちなみに僕はvim派です。出社したらまずはブラウザ・ターミナル・IRCクラインアント・Twitterクライアント・iTunesを立ち上げ、可能な限りその中から出ないことを心がけています。 前回は同じチームのgaoohさんがEclipseによるAndroid開発環境の作り方を解説していましたが、今回はそれに便乗して、出来るかぎりターミナルから出たくない不精者のためのEclipseを使わないAndroid開発環境を作るときに押さえておくべきことを、リーダーに言われてもいないのにまとめてみまし
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしている エンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか?p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも
前回の記事:C++0x Memory Model 第0回 - メモリモデルとは何か 以下では, C++0x プログラミング言語の標準規格として一貫して N3225 を参照しています.文中で (1.9/12) などという表現が出てきた場合は N3225 における条項を指しています. 太字かつ斜字体の言葉 は N3225 で C++0x で定義される用語, 太字の言葉 は本ブログエントリ中で特別な意味を持たせた用語として定義しているものです. 第1回目のこの記事では,まず,ただ1つの 実行スレッド thread of execution だけを考慮した場合のメモリモデルに関わる基本的な事項を説明していきます.複数スレッドが存在する状況下でのメモリモデルに関する説明する上で,単一の実行スレッド内に限定した場合の状況を把握しておくことは必要不可欠なのです. 第0回において,プログラム中にただ1つの
5分でわかる Ruby を知らない人が Ruby の便利さを学べる記事をかいたよ って記事があってとっても感動しました。RubyではRailsとかSinatraとかのWebアプリのフレームワークが流行っていますが、もっとお手軽にちょっと便利な使い方を紹介するのっていいですよね!! ただ書き方が少し冗長なコードが多くて、元ネタのPHPよりもRubyが長ったらしいと誤解されてしまっている節があります。 もうちょっと短く書けるよ!! ってことで書きなおしてみました。 >コピーライトの西暦を自動更新 >Ruby を使えばページフッタの西暦も自動更新します。 before Copyright (c) 20010-<%= Time.now.strftime("%Y") %> Weble inc. All Rights Reserved. Time#yearってメソッドがあるのでそっち使ったほうが素直で
明けましておめでとうございます! 近年、個人でWebサービスを開発するのが流行っていますね。「今年こそは俺もWebサービスを作ってモテモテになるぜ!」と思っている人も多いのではないでしょうか。 そんな人のために、Webサービスを開発・運営するにあたっての心構えやノウハウ、体験談などの書かれたエントリーを集めてみました。 ▼誠 Biz.ID:田口元の「ひとりで作るネットサービス」探訪 個人でWebサービスを開発している人たちのインタビュー集。ヒットしたサービスを手がけた個人開発者達のバックグランドや考え方を垣間見ることができ、モチベーションアップにもなります。恥ずかしながら、私のインタビューも載っています。 ▼Web2.0ナビ: 個人サービスを作るコツ 個人がWebサービスを作るための、実践的な8つのコツが書かれています。 ▼個人でネットサービスを運営するための5つのコツ(momose版):
トラックバック一覧 1. バグはいつか仕様に変わる? [地方で活動するweb制作者の日々を綴るblog] 2007年07月18日 14:25 「バグは夜更け過ぎに仕様に変わるだろう」 というのは、IT屋さんの中では有名な格言らしいのですが(私は知りませんでしたが)、その全文版を公開したそうです。 業界の人なら受けること間違いなし。 そして、現実と照らし合わせてぞっとすることも間違いなし。 IT 業... 2. 2007年7月18日 1907年はこんな時代 [神戸の三代目] 2007年07月18日 20:04 またヤフー株が米国につられて下げてる・・。誰かアナリスト、ちゃんと指摘してよー。ネタ加藤一二三九段伝説 前も書いた気もするけど、加藤一二三が凄い(というか面白い)。 一芸に秀でている人はぶっ飛んでいる人が多 3. [研究室][雑記] [Gabari] 2007年07月18日 20:22
伊東まで開発合宿に行って、みんなでC言語のコーディングスタイルチェッカーを作ってました。 => KariyaSiesta | C 言語向けのコーディングチェッカ 配布サイトも作りました。 ルールを簡単にカスタマイズできるようになってるので、みんな使うといいでゲソ。 特徴 Eclipseのプラグインとして使える Eclipseプラグインとして実装されているので、IDEで使えます。 もちろんCDTとも組合せることができます。 簡単イントール 更新サイトから簡単にインストールできます。 もちろん自動アップデートにも対応してます。 XPathでルールで書ける ルールはXPathで書くことができます。 例えば『whileの内でbreakを使ってはいけない』というルールは以下のようになります。 こまかい書き方はマニュアルを参考にしてください。 //Stmt[@sort="While" and .//k
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」(Empirical Software Engineering、実証的ソフトウェア工学)です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は? マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く