タグ

designとProgrammingに関するihokのブックマーク (15)

  • 7 Must Know Software Design Patterns

    Photo by charlesdeluvio on UnsplashWhy Should We Care About Design PatternsSimply put, design patterns help us solve problems by creating a reusable solution that we can use as a template for our software. That being said, design patterns aren't algorithms and you can't paste them into the code base. They give you a template of sorts, but if misused some patterns may cause additional complexity an

    7 Must Know Software Design Patterns
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
  • Rubyはどのように生まれ、世界へ羽ばたいていったのか?まつもとゆきひろさん講演会の全貌をレポート – NET BIZ DIV. TECH BLOG

    どうですか? Rubyって新参者のイメージがあると思うんですけど、実はJavaと同じぐらい古いんですよ。 ちなみに、World Wide Webの原型になるものが作られたのは1990年だったそうです。Rubyを作りはじめた当時の1993年の時点では、World Wide Web自体は存在はしていたのですが、世間一般にはほとんど認知されていませんでした。つまり、冒頭でも申し上げたとおり、Rubyはweb用に開発されたわけではなかったのです。 当時すでに先輩としてPerlという言語があったのですが、その代わりになるような言語を作りたかった。でも単にまったく同じものを作ってもしょうがない。その頃の私はオブジェクト指向に傾倒していたので、こう考えました。 「オブジェクト指向に基づいて言語をデザインすることで、既存のものよりも良い言語が作れるんじゃないか」 ―― それがRubyの始まりです。 国際色

    Rubyはどのように生まれ、世界へ羽ばたいていったのか?まつもとゆきひろさん講演会の全貌をレポート – NET BIZ DIV. TECH BLOG
  • 宣言ブロックのCSS設計 - kojika17

    語で「CSS設計」を検索すると、記事やつぶやきなどでセレクタの命名規則に関する話題が多いです。 CSSを設計する上で、命名規則は重要な要素でしょう。 簡単なセレクタ名だと他のスタイルと重複する可能性もあります。他のスタイルと重複しないようにセレクタの子孫数を増やしてしまうと、今度はスタイルの取り回しが悪くなります。 またデザインをコンポーネントに分ける粒度について紹介されていますが、命名規則の分け方のように紹介されているよう感じます。 論理的に構造をわけて命名していくため、覚えやすく、伝えやすさもあわさって、現在の「CSS設計 = 命名規則」のような構図ができあがったと感じています。 CSS設計は命名規則だけか 命名規則CSS設計において、重要な要素です。 しかしCSS命名規則させ気を付ければ良い、というものではありません。 私は、すでにあるサイトの一部のコンテンツの作成やすでに用

    宣言ブロックのCSS設計 - kojika17
  • 【デザイナー向け】これからAndroidのデザインをする人へ - Qiita

    はじめに 自己紹介 私は日Androidが上陸したAndroid 1.6の時代(2009年頃)からAndroidの開発者としてAndroid7系になった今も(執筆時2017年)Androidエンジニアを続けています。 Android歴史をずっと側で見守り続けた私がエンジニア目線で思っている事を述べるので、これからAndroidのデザインをするデザイナーに見て頂きたいです。 ※ この記事の内容は一個人の意見で所属先は一切関係ありません 一番言いたいこと まず、普段iPhoneを使っているデザイナーは最新もしくは1つ前のOSが入ったAndroid端末をメイン端末とまではいかなくても2台持ちにして常用して下さい。 ハッキリ言ってこれが全てです!! 良さ気なUIのアプリを一通り入れて数十分触るだけでは全く意味がありません。 Androidの良さは通知やIntentと呼ばれるアプリ間の密な連携

    【デザイナー向け】これからAndroidのデザインをする人へ - Qiita
  • 関数の仕様を正しく実装していることをどう保証するのか - $shibayu36->blog;

    静的型チェックがあったらテストはあまり書かなくて良いのか - $shibayu36->blog; で静的型チェックがあったとしても、テストをあまり書かなくて良いわけではないという話を書いた。するとブコメでいろいろ意見をもらえた。これらの意見から、関数の仕様を正しく実装していることをどう保証するのかについてもう少し深く考えてみようと思い、その考えがまとまってきたので、ブログに書いておく。 一応前提として、今回の話は自分の経験とこれまでのを読んだ知識を元に自分で考えたものであり、何かの理論に則って話しているわけではない。この部分が違うなどあれば突っ込みを受けたい。 今回考える仕様 このようなことを考える時、非常にシンプルに考えたほうが理解がしやすいので、以下の様な仕様を持つ関数addNaturalIntを考える。 関数addNaturalIntは正の整数を二つ受け取り、足しあわせて正の整数を

    関数の仕様を正しく実装していることをどう保証するのか - $shibayu36->blog;
  • その文字、薄すぎない? デザインにおける灰色の明度は何%が最適か

    UX Movementにおいて記者、編集長を務めます。明快で効果的なデザインに美点を見出し、利用者のために払う労力を惜しみません。 一言で灰色と言っても、明るいものもあれば暗いものもあり、実に様々なバリエーションがあります。Webサイトなどでは、いたるところでお目にかかることのできる色でもあります。濃い灰色は主に見出しや文に、薄い灰色はメタデータ、分類名、説明文に多く使われます。これらの色合いのうち、最も乱用されるのは薄い灰色です。 薄い灰色の文字の問題点 文字色として薄すぎる灰色は可読性に問題を起こしかねません。灰色の文字を薄くしすぎてしまえば、読者が読むにあたって支障をきたすことになります。文字の明度によっては、薄い色の背景に混ざってしまうのです。この現象は、単語や文字をぼやけさせ、判読を困難にします。無理に判読を試みれば、目を傷めてしまうでしょう。 また、薄い灰色の文字は読者の誘導

    その文字、薄すぎない? デザインにおける灰色の明度は何%が最適か
  • オブジェクト指向UX | POSTD

    (注:2015/11/18、記事およびタイトルを一部修正いたしました。) CNN.com で働いていた2012年6月に、大統領選挙投票日の夜のユーザエクスペリエンス(以後UX)のデザインを任されました。私はそれからの6カ月間を投票日の夜のための仕事に専念しました。しかし、仕事が成功するかしないかは、選挙結果に関係はありませんでした。私が懸念していたのは、情報の見つけやすさやデータの見やすさ、canvasでのオブジェクトの変形、そして一体どのようにしたら、iPhoneでマウスオーバーのフライアウトが動作するのかでした。CNN.com史上初めてWebデザインをレスポンシブにすることにしたのです。さらに史上初めて私が、その デザイン を担当することになったのです。 大きな賭けでした。CNN.comにとって大統領選挙投票日の夜と言えば、スーパーボウル(プロアメリカンフットボールの優勝決定戦)の日曜

    オブジェクト指向UX | POSTD
  • クラス設計の原則 — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと

    クラス設計の原則 — みんなのウェディングエンジニアリングブログ
  • サービス提供終了のお知らせ

    日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 <アレスネットをご契約のお客様へ> 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート

  • I have created 50 games in 2014 - ABA Games

    I have created 50 mini browser games this year. This is it. Click the image to play the game. Games are roughly placed as follows.

    I have created 50 games in 2014 - ABA Games
  • インターフェイスを設計するために読んだ技術書まとめ - 自由課題

    アーキテクトの(機能面での)主要な仕事の1つに、システムを構成するサブシステム/コンポーネントの境界、つまりインターフェイスを決める、というものがあります。またはそこまで大げさに捉えなくても、例えばライブラリのAPIを設計する、というのは単にプログラミングをする、ということとは少し違う視点が求められるように思います。 案外インターフェイスを考えるという観点での技術書まとめがないような気がしたので、需要があるかわかりませんが関連して読んだを紹介しておきます。なお、個人的なキャリア上、C++/Javaが対象です。(色々経験したら随時追加するかも知れません) 何か他にいいがあったらぜひ教えてください。 言語仕様をきちんと知る まずはAPIを設計する対象言語をよく知る、ということは必要であると思います。これだけだと、結果的にプログラミングに精通するということとあまり変わりはないかも知れません。

    インターフェイスを設計するために読んだ技術書まとめ - 自由課題
  • 「駅すぱあと」を支える技術とDSLの話 - だいくしー(@daiksy)のはてなブログ

    「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) というイベントが開催された。 ぼくも会場係としてスタッフ参加。 「駅すぱあと」の歴史から技術、開発のマネジメント手法に至るまで、幅広い話が聞ける良いイベントだった。 いろいろな話が聞けたのだけれど、僕は特に佐藤さんの「『駅すぱあと』新しい開発基盤の研究」がおもしろかった。 まだ開発途中で、実際の駅すぱあとには組み込まれていないそうなのだけれど、佐藤さんは「駅すぱあと」の運賃計算のDSLを研究・開発しているという。 曰く、鉄道の運賃計算は泥沼である。単純に距離や、目的地までの駅数などで運賃が算出できればよいが、鉄道の運賃計算には無数の特例がある。 下記リンク先に、JRの運賃の特例計算が列挙されているので、ちょっと見ていただきたい。 ……お分かりいただけただろうか。現在の「駅すぱあと」では、これらの特例がすべ

    「駅すぱあと」を支える技術とDSLの話 - だいくしー(@daiksy)のはてなブログ
  • 主キーはインデックスではない - 設計者の発言

    仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス(キー)というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセ

    主キーはインデックスではない - 設計者の発言
  • 定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)

    いやー、この問題は当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの?老害なの?」 とか言わないで欲しい。この問題、当に難しいんだよ! ■ 1度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり

  • 1