タグ

ブックマーク / postd.cc (5)

  • 私が挫折を繰り返したのちにコーディングを習得するに至った経緯 | POSTD

    Project Eulerは、プログラミングを楽しく段階的に学ぶ手段を提供するWebサイトです。 Colin Hughesが11歳くらいの時、彼の両親は何とも変わったおもちゃを家に持ち帰りました。それはカラフルでもなく、漫画のようなものでもありません。レーザや車輪、点滅するライトが付いているようにも見えませんでした。しかも、そのおもちゃの箱に描かれていたのは、カッコいい主人公や悪役の姿ではなく、箇条書きの文とQWERTYキーボードの絵でした。そのおもちゃの名は、「ORIC-1 Micro Computer」です。中にはカセットテープが2つと、数のコード、そして130ページに及ぶプログラミングのマニュアルが入っていました。 どう考えても、11歳の少年には最悪のプレゼントでしょう。それでも彼の両親は129ポンド(当時の為替レートで約4万5000円)以上するものを買ったという理由もあって、とに

    私が挫折を繰り返したのちにコーディングを習得するに至った経緯 | POSTD
    bricklife
    bricklife 2015/09/04
    「学校で履修されている数学を見るのは心が痛む」「創造することのスリルや喜び、痛みや苦しみまでもが失われます」
  • あなたと働くエンジニアの人生を最悪なものにしないために – デザイナーのための3つの提言 | POSTD

    それとも、”私はデザイナーなので、そんなことを知る必要はありません”と言い張るのか 私の職業はデザイナーです。私はエンジニアが好きです。ちょっと度が過ぎるくらい好きかもしれません。以前、Facebookの グループ に参加した時、かなり前からチームのメンバであるiOSのエンジニアと初めて話して、口から泡を吹いたことを思い出します。私はその時、これまでに自分がObjective-Cでコーディングしたものについて、勢い込んで話し始めました。まるで、高校の新入生が、上流階級の生徒に対して、自分が付き合う価値のあるカッコいい人間だと証明しようとしているみたいだと感じました。 デザイナーの多くが、エンジニアとの話し合い方を実はよく分かっていないと思います。もちろん、デザイナーはエンジニアと話しますが、当の意味で関わろうとしていません。この記事を書いた理由はそこにあります。ソフトウェアエンジニアの懸

    あなたと働くエンジニアの人生を最悪なものにしないために – デザイナーのための3つの提言 | POSTD
    bricklife
    bricklife 2015/08/14
    Framer/Origami推し「もしインタラクションがエクスペリエンスにとって重要ならば、それをプロトタイプにするのはあなたの仕事です」
  • クレジットカードフォームの解剖学 | POSTD

    オンラインでクレジットカードを使って支払うことは簡単ですよね?この答えはYesでもNoでもあります。Yesの理由は、インターネットが普及された初期からずっとそうしていたから(例:Amazon)。Noの理由は、まったく同じクレジットカードフォームは2つとないからです。 過去20年以上で、私たちはオンライン支払のメンタルモデルを作り上げてきました。「財布からクレジットカードを取り出して、ウェブのフォームに必要なカード情報を入力、そして申込みボタンを押す」というものです。しかし、ユーザーが答えないといけない質問でいっぱいなので、全てを入力するのはとてもややこしい行為になってしまいます。そして言うまでもなく、誰も取扱い説明書なんて読みたくありません。 さまざまな有名ウェブサイト・アプリのクレジットカードフォーム 何かの代金をオンラインで支払う時は、人へ支払う時より2,3倍遅れをとります。端末のボタ

    クレジットカードフォームの解剖学 | POSTD
    bricklife
    bricklife 2015/08/12
    よく考えられてるわー 「私たちのゴールは、多様な入力事項とユーザーが疑問に思う箇所全てについて、その意味がわかるようにすること」
  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
    bricklife
    bricklife 2015/07/06
    「1つのテストに3つ以上モックがある場合は再考が必要」「褒める、グッドプラクティスを強化する」
  • Optimizelyを使ってクビになりかけたワケ ~統計学が苦手なマーケターへの薦め~ | POSTD

    (訳者注: 検定手法について、この記事には一部内容が古い部分があります。Optimizelyは現在、両側検定を採用し、独自開発したより精度の高い統計手法(Stats Engine)でテスト結果を表示しています。Stats Engineに関する記事: 日語 ・ 英語 ) 私たちがSumAllでA/Bテストを一斉にスタートさせて6ヶ月が経ち、あまりよくない結末を迎えました。それは勝算があるとした結果のほとんどが新規ユーザーの獲得改善にはつながらなかったことです。それどころか、私たちは失敗したのです。そして私の一番の責任はユーザー獲得の増加であるということを考えると、当に最悪の状況でした。私にとっても、私のキャリアにとっても、そしてSumAllにとっても。 過去に A/BテストとWebサイト・パーソナライゼーションの会社 に勤めていた経験から(はっきり言うとMonetateはOptimize

    Optimizelyを使ってクビになりかけたワケ ~統計学が苦手なマーケターへの薦め~ | POSTD
    bricklife
    bricklife 2014/11/11
    「統計や標本サイズなど有効なA/Bテストを行うのに必要なことを理解しているマーケターはほとんどいません」「重要なのは変動サイクル」
  • 1