We take the information from public sources, then structure it for your quick and convenient search for the websites that probably belong to the same owner.
※このエントリは、Arata Kojima/NPO法人しゃらく さんが公開しているわかりやすい技術文章の書き方の改変です。 このページは、プログラムやコードなどを書く方々のために、分かりやすいプログラムを書くためにはどうすればよいのかについて説明しています。 1. 自分が伝えたいこと・訴えたいことを誤解しないように相手に読んでもらうにはどうするべきか。 2. プログラムを書くにあたって知っておくべきルールは何か。 3. プログラムを書く前にどのような手順を踏めば、分かりやすいプログラムを作れるか。 などについて参考にしていただければ幸いです。 プログラムを書く前に プログラムを書く前に次のことをしっかりとイメージしておく。 何を書くのか。 書こうとしている物は正確に何であるのか。 仮定して良い、必ず成り立つ前提(状況/状態)は何か。 成り立つ事が単に多いだけ/今はたまたま成り立っている、と
Smashing Magazine - WE SMASH YOU WITH THE INFORMATION THAT WILL MAKE YOUR LIFE EASIER, REALLY. Chris Coyier氏がSmashing Magazineにおいて12 Principles For Keeping Your Code CleanのタイトルのもとHTMLコードをクリーンにするための12の原則を紹介している。厳密には11の原則だが、HTMLをクリーンに保つ上で実践的で効果的なものだ。WebデザイナやWebデベロッパは一度チェックしておきたい。12 Principles For Keeping Your Code Cleanで紹介されている原則を要約すると次のようになる。 [原則1] HTML 4.01を採用する場合でもXHTML 1.0を採用する場合でもStrict指定のDOCTY
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
※ 一部の画面はデモより Googleの高度なエンジニアリングを支える技術の一つにソースコードレビューがある。ソースの修正点について、レビューし、議論することでさらに良いコードができあがっていく。世界中にいるエンジニアのために、議論はネットを介して行うことになる。 ソースコードの行ごとにコメントが書ける そのためのシステムがMondrianだ。これを作ったのはGuido van Rossum氏、Python開発者でもある方だ。そしてこのMondrianをなんとかオープンソースとして公開したいと願ってきたRossum氏が実現させたのがこのソフトウェアだ。 今回紹介するオープンソース・ソフトウェアはRietveld、Google App Engineで作られたソースコードレビューシステムだ。 Rietveldは任意のリポジトリに対して、古い版と新しい版のソースの差分を表示し、レビューを行うこと
2007年12月06日13:00 カテゴリLogos プログラマーでなくてもわかるaとtheの違い 簡単です。 codeなにがし::プログラマにおくる英語の冠詞の使い分けの法則 Wiki版 実は冠詞の使い分けに関しては、プログラムを書く人間であれば即座に理解できる法則があります。 a それと別物を置き換えても文章が成り立つ場合。 どれでもいいのが a the それでないと文章が成り立たない場合。 それじゃないと駄目なのが the だから乞食は"Would you give me a quarter."(25セントくれ)と言うのに、取引では"Give me the money."(その金よこせ)と言うわけです....というのは半分冗談ですが、そういうことです。 1962-1966 The Beatles anyとsomeもついでに覚えちゃえ ついで、というより、このことは any と som
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年~98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
なかなかハードルが高く,多くの人が踏み出せないでいるカーネルのソース・コードの読解。本連載では,今までカーネル・ソースなんて見たことがないという人に,読みこなすコツをお教えします。今回は,どうしたらカーネル・ソースを読みこなせるようになるのか,筆者の経験をお話します。 Linuxユーザーなら誰しもカーネルのソース・コード(カーネル・ソース)を読んで,どのような処理を行っているのかを確認したり,自分なりの変更を加えたりしたくなるのではないでしょうか。しかし,カーネル・ソースの量は膨大な上,C言語で書かれているので,コンピュータ内部やOS(オペレーティング・システム)の仕組みを理解したプログラマでないとなかなか読みこなせません。そのため,カーネルを読むための第一歩を踏み出せない人が数多くいることは事実です。 本講座では,プログラマではないごく普通のLinuxユーザーが,カーネルをある程度自力で
DBを使った開発であれば必ず出てくるのがマスタメンテナンス画面だ。同じような作りで、毎度作るのが面倒に感じている人も多いだろう。だが、ユーザのためを考えれば必ず必要なのもわかっているはずだ。 せめて手軽に終わらせられるようにしよう。決まりきったコードは自動生成してしまえば良い。 今回紹介するオープンソース・ソフトウェアはphpCodeGenerator、DB定義に沿ってコードを自動生成するソフトウェアだ。 phpCodeGeneratorの特徴はなんと言っても対応しているDBの多さだ。MySQL、PostgreSQL、Oracleといった基本的なものはもちろん、Access/ODBC/SQLite/DB2/MS SQL Server/MaxDB/Visual FoxPro/FrontBase/InterBase 6/Borland Interbase 6.5/Firebird/Inform
「Code Reading―オープンソースから学ぶソフトウェア開発技法」(毎日コミュニケーションズ発行,写真1)という本があります。私はこの本の監訳者ですから,やや自画自賛になってしまいますが,ソースコードの読み方を主題にした本はほかにはあまりありません。技法からツール,データ構造,アーキテクチャ,さらには実際にコードを読んで利用する実例まで紹介している網羅的で良い本だと思います。 この本の「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家,他人の筆づかいを研究しなかった偉大な画家,同僚の肩越しに技を盗まなかった腕のよい外科医,副操縦席で実地の経験を積まなかった767機長――果たして,そんな人たちが本当にいるのでしょうか? たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち,他の人の
Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い!情報の正確性は自己責任で判断してください。 Webに言語は数あれど、特に玉石混淆の激しいJavascriptの書き方について纏めてみた。間違い指摘大歓迎! 発端はYahoo!の Eric Miraglia による、YUI 式モジュールの作り方をまとめた記事。ざっくりまとめると、以下の手順になる。 YAHOO.myProject.myModule = function () { //"private" variables: var myPrivateVar = "I can be accessed only from within YAHOO.myProject.myModule."; //"private" m
最近、CSS の使いまわしなどを視野に入れ、一部で class名や id名の共有というテーマへの関心が徐々に高まりつつあるような印象です。microformats なんかも、その流れのひとつといえるでしょう。 Naming conventions table(And all that Malarkey) もう、class名やid名で悩まないんだからっ!!(CSS HappyLife) (X)HTML の id/class における命名規則(purprin さん CSS Flight プレゼンスライド) 名前の共有はコードの共有のための(複数人で同一コードを編集・転用する)重要なファクターのひとつですし、非常にいい傾向だとは思うんですけど、実際につけられている名前を見てみると、シブい顔をせざるを得ない事例が結構あるようです。 コード共有のためには避けたい命名事例 構造ではなく見栄えで命名して
「Fun With Google Code Search」によると、 Google Code Searchを使って脆弱なソフトウェアを見つけられてしまうそうです。 実際に、Google Code Search経由で発見されてサーバを乗っ取られた事例が「How Hackers Are Using Google To Pwn Your Site」という記事で紹介されています。 ShoeMoneyが乗っ取られた事例では、恐らくWebサーバの設定ミスで.phpファイルの関連付けを行わない状態で、Google Sitemapsに登録してしまったため、Google Code Searchに自作コードが載ってしまい、それを見たクラッカーがサイトを乗っ取ったのであろうと思われます。 バッファオーバーフロー strcpy : strcpy\((\w+,\w+) lang:c sprintf : (sprin
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード=大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
[更新 2018] 2012年にサービス終了しています。 噂になっていたGoogleのコード検索サービスGoogle Code SearchがGoogle Labsから公開された。 例: “Romaji”でソースコード検索 上の検索結果からすると、Camel Notation中の単語も探してくれるみたいだ。 IsProgrammerDifferentFromSE()みたいなネーミングからも単語を切り出してインデックスしているということで、これはありがたいかも。 見つかったコードをクリックすると、キーワードハイライトされたソースコード全文、同じディレクトリ内にある他のコードのリスト、パッケージやコードのGoogleキャッシュ(!)、パッケージのダウンロードリンク、などが表示される詳細画面に移る。 検索では、トップページ下にも説明がいくつか書かれているが、言語、ライセンス、パッケージ形式やファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く