Perl › here Perl5.8以降における標準的なPerlの書き方を解説します。 インターネットで検索するとPerl4のころの古い記述がたくさんあります。また書籍などの多くもPerl4の記法で書かれています。Perl4の記法は複雑になりやすく間違いを生みやすいのでこれからPerlを書く人はPerl5の現代的な記法で記述することを強くお勧めします。 strictプラグマとwarningsプラグマ (必須) strictプラグマとwarningsプラグマを有効にします。 use strict; use warnings; use strict;とuse warnings;の２行はスクリプトの最初に必ず記述してください。これらはPerlの文法チェックを厳しくするためのものです。面倒だという軽い気持ちでこれを記述しないと後々本当に面倒なことになります。 use strict;とuse wa

NTTドコモは10月23日、ソフトウェアの不具合対応に伴い、iモードブラウザの一部機能を停止していた機種について、ソフトウェアアップデートを順次提供することを発表した。これにより、JavaScriptなどがiモードブラウザで利用可能になる。 NTTドコモは2009年夏モデル以降の機種に、iモードブラウザ2.0とよばれる新ブラウザを搭載し、JavaScriptやCookie、Refererなどに対応した。しかし、「有料会員登録をしていないにもかかわらず、有料コンテンツが利用できるなどの不具合が生じた」（NTTドコモ広報）ため、一部機能を停止したうえで端末を販売していた。 対象端末は、docomo STYLE seriesの「F-08A」「N-08A」「P-08A」「SH-05A」「SH-08A」、docomo PRIME seriesの「F-09A」「N-06A」「N-07A」「P-07A」

今回はTestLinkをテスト工程でどのように使うのか、テスト特有のマネジメント手法や概念を、TestLinkの機能に合わせて詳しく説明した。 【1】TestLinkの概要 TestLinkはPHPで作られたテスト管理Webシステムである。最新版はVer 1.8.3 （2009年6月）で、GPLで公開されている。WAMP、LAMP環境で動作する。 主な機能は下記である。 （参考：「きちんと学びたいテストエンジニアのためのTestLink入門」（gihyo.jp）、「簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト」） 数千から数万のテストケースを一括登録して貯蔵できるので、テストケースを再利用できる テストケースとは別に、テスト実施結果を履歴として残せる テスト実施結果をいろいろな観点で集計できる テストケースからバグ管理システムと連携してバグ修正

オペラソフトウェアが中心となり、Yahoo!やWaSP（The Web Standards Project）などが協力して作成した、Web標準を学ぶためのオンラインコンテンツ「Web標準カリキュラム」日本語訳の一部公開が開始されました。 翻訳を行っているのは、W3Cの標準化動向などをブログで紹介していることでも知られる企業ミツエーリンクス。日本語訳の公開も、同社のブログのエントリ「Web標準カリキュラム 日本語訳の公開を開始 | Web標準Blog | ミツエーリンクス」で明らかにされました。 「Web標準カリキュラム」のオリジナルは英語版の「Opera Web Standards Curriculum」。全体で10章もある重量級のコンテンツです。 Introduction to the world of web standards Web Design Concepts HTML bas

Buyer Protection Program When you buy a domain name at Dan.com, you’re automatically covered by our unique Buyer Protection Program. Read more about how we keep you safe on our Trust and Security page. Next to our secure domain ownership transfer process, we strictly monitor all transactions. If anything looks weird, we take immediate action. And if the seller doesn't deliver on their part of the

増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,

Pirka'rはWindows/Mac OSX/Linux向けのフリーウェア（ソースコードは公開されている）。ここ数年でブラウザのシェアは大きく変わってきている。それまでIEが主流だったのがFirefoxが大きくシェアを取り、さらにSafariやGoogle Chromeといったブラウザが続いている。特にCSSやJavaScriptの互換性の問題もあってIE系ブラウザが嫌われる状況になっている。 検証もできる ユーザにとって選択肢が増えるのは良いことだが、開発者やデザイナーにとっては辛い。JavaScriptの動作やレンダリング結果にブラウザによる差異があるとなっては確認作業も大変になる。その手助けをしてくれるツールがPirka'r（ピリカル）だ。 Pirka'rはEclipseベースの開発支援ソフトウェアで、HTMLファイルやJavaScript、CSSファイルのメンテナンスを行うことが

開発の全工程の中で、あまり人気がないのがテスト工程だ。ソフトウェアの品質を証明するためのテストは、なぜ低く見られてしまうのか（編集部） そもそもテストはなぜ実施するの？ 皆さんはテストと聞いてどういったイメージをお持ちでしょうか。 「面倒くさい」「プログラマの仕事じゃない」「納期直前に徹夜でするもの」「そもそもしない」……。 残念ながら筆者の周りにいる開発者に聞いてみても、あまり人気のある工程とはいえないようです。 さて、本連載で扱うテストとは、もちろん学期末の終わりに実施するような人の知識、習熟度を試すテストではありません。ソフトウェア開発におけるテスト、つまり「ソフトウェアの品質を証明するためのテスト」のことです。自分たちが作り上げたソフトウェアに対して自らテストし品質を評価する工程、そして、テスト結果は常に100点である必要があるという半ば自己満足的な性質を持つ試験のことです。 しか

ドットインストール代表のライフハックブログ

これはデザイナーのみならず導入必須のソフトウェアと言えそうだ。 Webサイトを作る際には、モックアップが必要になる。それをベースにして「ここをこうしよう」「次はどこに遷移させよう」といった議論が可能になる。頭の中だけではイメージがはっきりせず、意見も出しづらい。 ドラッグアンドドロップでモックアップを作成できる そんなモックアップを作成しようと思ったら、紙やHTMLオーソライズソフトウェア、画像編集ソフトウェアを使うことが多かった。だが画像編集ソフトウェアではチェックボックスやテキストボックスが作りづらい、HTMLオーソライズソフトウェアではデザインの微調整が面倒、紙では重ね書きしづらい…とそれぞれに欠点があった。そこでこれを導入してみよう。 今回紹介するオープンソース・ソフトウェアはPencil、Firefoxアドオンとして動作するモックアップ作成ソフトウェアだ。 個人的にはモックアップ

デザインの変更の手間を防ぐ為にWEB制作時にはコーディングしていないモックアップをデザイン案として見せるのが主流だと思います。今日紹介するのはラフなモックアップをドラッグ＆ドロップで簡単に作成できるWEBツール「Balsamiq Mockups」です。 パーツをおいていくような感覚で簡単に作成できます。実際「Balsamiq Mockups」を使って制作しているイントロムービーがYouTubeにアップロードされていましたので、下記に貼付けておきます。 動画は以下から 上記のように簡単にモックアップを制作していく事が可能です。デザインの詰めの部分まではできませんが、構成要素の確認であれば十分な物が作れます。慣れないうちはイラストレーターやphotoshopでざっくり作った方が早いと言う方もいるかと思いますが、最初からパーツが揃っているので、慣れてくればかなり素早くモックを起こす事ができそうで

先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出