The Blog | Welcome to Adobe Blog アドビのブログでは、Creative Cloud、Document Cloud、Experience Cloudの最新情報や役に立つ情報を紹介しています。
![The Blog | Welcome to Adobe Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/384feb49f19024293f218545a6a4175e78ec5e35/height=288;version=1;width=512/https%3A%2F%2Fblog.adobe.com%2Fdefault-meta-image.png%3Fwidth%3D1200%26format%3Dpjpg%26optimize%3Dmedium)
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます! と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
この文脈では、「編集内容のキャンセル」という処理を続行しても良いかをユーザーに確認しています。続行に同意したい多くのユーザーは直感的に同じ表記の「キャンセル」を押したくなるでしょう。しかしそれでは編集のキャンセルが実行されません。 このキャンセルボタンが意味するのは、「『編集内容をキャンセルする』のキャンセル」なのです。つまり、ユーザーが望み通りに編集内容を破棄するためには、反対側のOKボタンを選ぶべきなのです。このような「キャンセルのキャンセル」は二重否定で意味がややこしくなるので避けなければなりません。 ここで「キャンセルのキャンセル」にならなければ良いということで、次のようにボタン名を変えてみました。 これでもう迷うことは無くなりましたか……? 私はこの修正は誤りだと判断します。「はい」「いいえ」は結果を予想しにくい表現なので、ダイアログのアクションボタンに用いることはあまり適切では
めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね?という話。 ここで言う「ハマる」とはなにかに夢中になって没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。 先日、ハマった問題が解決した時の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが!」という前任者への怒りが混ざった状態だった。 サイトのSSLの有効期限切れが2週間後にせまっていた。やる事は証明書の更新、新しい証明書をAWSのELBに入れること。ただこれだけ。しかしハマった。どうやってもELBから「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。2年前にSSLを設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすればOkなはずなのに、なぜかできなかった。
モチベーションの高いエンジニア... ガンガン働いてくれそうで、放っておいても安心でしょうか? 安心してください。 簡単に下げられますよっ! o 序の口: ディスプレイを小さくする o 序二段: 毎日スーツを着させる o 三段目: 椅子を固くして、机を狭くする o 幕下: 簡単に作れるでしょ?って上から目線で言う o 十両: 打ち合わせ一杯で連続した集中時間を与えない o 前頭: 情報共有しづらい、風通しの悪い現場に o 小結: 引き継ぎなしで人をどんどん入れ替える o 関脇: 背景わきまえず、コード汚い、仕組みひどいと言う o 大関: 仕事を突然終了させて無意味感を与える o 横綱: 本質的でないことに時間を取らせる仕組み 序の口: ディスプレイを小さくする エンジニアの仕事の多くはパソコンの中にあります。そのパソコンの中を覗く唯一の手段はディスプレイです。そんな狭い中で、色々な資料をみ
Updated 2015.04.27 / Published 2015.04.27 「ファーストビューが全て」のようなファーストビューについては盲信的な記事も多く、ファーストビュー云々のことで煙が立ち始めて、火がついてしまうと、上手く説得を試みようにも聞く耳をもってもらえず、困り果てるディレクター・デザイナーの方も多いのではないかと思います。ファーストビューはもちろん大事ですが、盲信的に傾倒することには疑問を感ぜざるを得ず、ファーストビュー問題はいつになっても考えものです。 ファーストビューのボヤは気付き難い ディレクターやデザイナーの方ならプロジェクトが進行していく中で、ファーストビューが問題になったことが一度や二度はありませんか。「いやいや、ファーストビューはちゃんとガチガチに予防線を張っているよ!」というディレクターの方も、きっと過去に苦い経験があるのではないでしょうか。 個人的にフ
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
コードのスニペット管理にSnippiを利用していたのですが、何故かTwitterアカウント連携ができなくなってしまい、こつこつ貯めていたコードが見られなくなってしまいました。 バックアップでNotefileに取ってあったため事なきは得たのですが、コードスニペット管理の方法としてはいかんせん使いにくい。 なんかいい方法あんめえかと思って探したところ、GitHubアカウントがあれば無料で使用できるスニペット管理ツールGistBoxが良さげだったので試してみたところ非常に快適でしたのでシェア。 参考:GistをメーラーのようなUIで管理する「GistBox」がいい感じ | REFLECTDESIGN メーラーのようなUI 使用はGistBoxでログインするか、Chromeアプリから。UIは一緒です。 私はChromeアプリを使用することにしました。 GistBox – Chrome ウェブストア
2013年も本当にあとわずかになりました。 本日は今年話題になったPHPについての記事を公式のリリースやはてなブックマークから抽出してきた内容を元に今年を振り返ってみましょう。PHPにとって今年はどのような一年だったのでしょうか。 参考: 2012年のPHP周辺の話題振り返り | Engine Yard Blog JP PHPのバージョン 2013年中にリリースされたPHPのバージョンは5.3、5.4、5.5の3系統で合計29のリリースが行われました。リリースサイクルはほぼ毎月という形でした。またPHPの公式サイトがレスポンシブ対応の新しいデザインに切り替わりました。詳細は下記の通りです。 Version 5.4.11 2013/1/17 Version 5.3.21 2013/1/17 Version 5.4.12 2013/2/21 Version 5.3.22 2013/2/21
We’re thrilled to announce the Runnable team is joining MuleSoft. This is an incredible opportunity for us to expand our vision of empowering developers to test changes without the infrastructure bottleneck; we couldn’t be more excited to work with MuleSoft to continue our journey. As apart of this transition, we’re shutting down service for all Runnable accounts. To those we had the joy of servin
Internet Week 2010 S3 今日こそわかる、安全なWebアプリの作り方2010 http://www.nic.ad.jp/iw2010/program/s3/
次世代Windwosの正式名称が「Windows 10」であるとマイクロソフトが発表し、なんで9じゃなくて10なの?とちらほらと話題になっています。 そんな中、次のツイートが数多くリツイートされ、9にしなかった理由の本命か?という声も出ています。 Windows8.1の次が10になった件は、バージョン判別しようとしてOS名を取得して前方一致で"Windows 9"だったら95/98系と見なすという糞コードが蔓延しているので避けたという話をFacebookで見かけた。説得力ありすぎる。— digitalcat (@digitalcat) 2014, 10月 2 ただ、ちょっと出典が曖昧でなんとなく都市伝説化?しそうだったので調べてみました。 まず、この説の初出はアメリカのソーシャルニュースサイト「reddit」です。 [–]cranbourne Microsoft dev here, the
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く