「画面」のデザインは、エンドユーザーから見た「プロダクト」との唯一の接点。超大事。 そんな画面のデザインにまつわる、エンジニアが「いじる」ときに気をつけると、もしかしたら面倒が減って争いが減ってみんなが幸せになれるんじゃないかなあ、とか、そもそもの設計上で考慮できると、もしかしたら使う人たちが幸せになれるんじゃないかなあ、というポイントを、思い付きで書いていくので、あとは誰か整理してほしい的な投げやり感あふれるアレコレ。デザインとコーディングの話を混ぜて書いてます。 空白の理由を考える編 その1. 空白にまつわる認識の相違 例えば、Tumblrのダッシュボード。右肩のメニューの隅までちゃんとレイアウトされてるなーって感じがします。 でも、もしあなたが「空白を理解しないエンジニア」だった場合、こんな感じにコーディングしてしまうかもしれません。 （※画像はイメージです） 「なーんか、素人感があ
Mac / iOS 開発担当の松本です。 以前同じチームのミヤモトさんが紹介記事を書いていた UIAutomation ですが、使いにくくて使っていませんでした。というのも以前のバージョンはコマンドラインからテストを実行できず、毎回 Instruments を手で起動して、、という残念な状態だったからです。 ところが iOS SDK 5からはコマンドラインからテストを実行できるようになったと言うので再度トライしてみました。 コマンドラインからテストの実行 手始めに下記のハローワールドをコマンドラインから実行してみます。 // hello_test.js UIALogger.logMessage("Hello, UI Automation!"); テストの実行は instruments コマンドで行います。 $ instruments \ -t /Developer/Platforms/iP
背景 いつも新しくboxを立ち上げる時は、Vagrantfileをつくってvagrant upして、vagrant sshして自分がいつも使ってる公開鍵を~/.ssh以下においてexitしてから、ssh vagrantとかしませんか？ちなみに以下みたいに設定したりしてますよね？ こういう風に書いてるならssh vagrantでVagrantに入れますよね？ もちろんいつもの自分の鍵をssh-add ~/.ssh/id_rsaしてる前提です。 書いてた で、その作業がめんどくさすぎて以下のスクリプトを自分は使ってます。 途中で秘密鍵のパスフレーズが途中で聞かれるので入力してください。 コメントがゆるふわなのは気にしないでください。 #!/bin/bash -eu echo べいぐらんとに自分のいつもつかってる公開鍵をつっこむよ！ echo べいぐらんが立ち上がってないなら起動 [ -z "`
前回のおさらい 前回はCalabash-iOSの導入方法について解説しました。今回からはGithubで公開されている01 Getting started guide · calabash/calabash-ios Wiki · GitHubを参考に、Calabash-iOSの使い方を解説していきたいと思います。 今回は公式ドキュメントにあるように、既に用意されているサンプルプロジェクトを使用して実際にCalabash-iOSを導入し、実行中のサンプルアプリに対してターミナルから対話的にコマンドを実行する方法を解説したいと思います。シナリオを早く書きたいところですが、何事も基本が大事！ということでまだ我慢してください。 サンプルプロジェクトを作成する まずは今回の解説に使用するサンプルプロジェクトを作成します。サンプルプロジェクトは既にGithubに公開されていますのでそちらをcloneする
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog LT の中で触れた環境を構築するデモコードを Vagrantfile にまとめて GitHub においていますのでよければ触ってみてください。ジョブ登録済の Jenkins が立ち上がるので全く同じ環境を試してもらえます。 yahoojapan/jenkins-with-docker-demo LT は5分でざっと流してしまったため、このエントリで補足します。 ジョブ実行毎にクリーンな環境がほしい 特に説明の必要もなく普段 Jenkins を使っていればジョブ毎にクリーンな環境がほしいと思うはずです。スレーブノードをジョブ毎に新規でインスタンスを立ちあげて実行することもできますが インスタンスの作成、起動はそれなりの時間がかかりま
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
