デザイン変更するときキャプチャ撮りまくると捗る - ✘╹◡╹✘
これまではどちらかと言うとDBやWeb APIみたいな開発作業が多かったけど、最近はHTML/CSSを触るようないわゆるWebデザイン的な作業をする機運が高まってきた。あんまりちゃんとやったことが無いために年始から色々と考えてて、まあその結実としてキャプチャ撮ると捗るという体験があったので書き残しておく。ちなみにキャプチャは無い。あとでデザイン変えたやつ公開したら過程を整理して紹介できると良いと思う。 過程を残すと意見をもらいやすい 『藤村龍至 プロトタイピング-模型とつぶやき』という本の中に、プロトタイプとして建築模型をつくっていく過程の話がある。与えられた条件を元にまず最もシンプルな状態から始め、課題を見つけながら少しずつ改善を加えていく様子が実例とともに紹介されている。この作業を反復しながら適用していくことで、模型の状態を都度更新していく。この方法には、設計者以外の人でも設計過程を見
ライゾマと真鍋大度さんの働きっぷりに見る、これからのエンジニアの在り方 #prfm
好きなものは空と緑とS2000とガンダムとラジコン・ミニ四駆、Perfume（かしゆか）。ときどき子育てとキャンプ。 先日の情熱大陸に出演され、もう多くの人が知っているエンジニア「真鍋大度」さん。 情熱大陸：真鍋大度 コンピューターを使って新たな表現に挑み続ける男の、制作の秘密と頭の中とは？ 怪しげで無口なこの男に密着すること半年。プログラミング？メディアアート？インタラクティブ？数々の難しい用語の先にある、真鍋の制作の神髄に迫った。 真鍋さんが所属するライゾマティクスでは現在 Perfumeの映像演出を手掛けており、先月ICCで行われた「Perfume inspired by ライゾマティクス展」ではその一部を見ることができました。 Perfumeと真鍋さんとの出会いはこんな感じ。 アーティスト・トーク「Perfume inspired by ライゾマティクス」議事録 - 3000年に会
開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage
なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」
svn な人のための これだけ読めば (もしかしたら) わかる (かもしれない) git の考え方 - rinu's blog
はじめに svn を使っていたあなたが、さくっと git の考え方を理解できますように (*・人・*) git リポジトリのイメージ git リポジトリのイメージを絵にしてみました。 絵の中の登場人物について、このあと触れますー リポジトリ リポジトリは複数のファイルの変更履歴を記録する入れ物です。 リポジトリを使用するときは、どこかにある、誰かのリポジトリを、自分のマシンにまるっとクローンを作って使用します。 (対して svn はある時点でのファイルのみを、ローカルに持ちます) コミット(図の黄緑の四角いあいつ) ファイル達に変更を重ねていくと、変化したファイル達の状態が、リポジトリに保存されていきます。 このリポジトリへ変更した内容を保存することを「コミットする」といい、保存されたファイル達の、変化の履歴の1つ1つを「コミット」といいます。 それぞれのコミットは 「0abe...」 み
アプリケーションをつくる英語
目指すは世界市場! 英語版アプリ開発のために、UIやメッセージでよく使われる英単語や構文パターン、さらに英語ライティングの基本やメッセージの書き方、I18N/L10Nの基本から翻訳業者への依頼まで、幅広く紹介。 サポートサイト著者によるサポートページが公開されています。 翻訳者 西野竜太郎 Webサイト 内容紹介最近スマートフォン用やWeb 用のマーケットが登場したことで、アプリケーションを海外に展開しやすくなりました。パソコンに加えてスマートフォンやタブレットといった新しい機器や、有線および無線の高速ネットワークが世界的に普及しつつあることを考えると、アプリケーションに対する需要は今後さらに拡大するものと思われます。海外は日本の開発者にとって魅力のある市場です。しかし海外展開には外国語での開発が必要となります。特に英語は世界共通語と位置付けられている面があるため、まず対応を考えるべき言語
パナソニックを退社しました
5月31日で、2年とちょっと働いたパナソニックを退社しました。最初半年ぐらいは研修だったので、実質1年半ぐらいで辞めたことになります。 辞めた理由はシンプルで、私はソフトウェアの開発がしたかったのですが、実際にはソフトウェアの開発が出来なかったこと。それから、社内の雰囲気が合わなかったことです。 もし今就活中、または来年就活の方で製造業を志望されているソフトウェアエンジニアの方がいたら参考になるかもしれませんので、少しだけ書いてみます。 ただ、大きな会社なので、部署によっては全然雰囲気が違うようで、楽しく仕事をしているところもあるようです。たまたま、私が合わなかっただけです。実際離職率は低めです。 それから、仕事の方針にはミスマッチはありましたが、部署の皆様には大変お世話になりましたし、私の考えに共感して助けてくださることもありました。特定の方を非難する意図はないことを申し添えておきます。
アプリの終わりの始まり
2012年2月27日から3月1日にかけてバルセロナで開催されたMobile World Congress 2012では、特に注目の集まったGoogleやFacebookのキーノート以外にも示唆に富んだ興味深いセッションが多数あった。その中の1つがコンサルティング会社frogのScott Jenson氏によるプレゼンテーションであった。同氏が各地で行っているというプレゼンテーションは“Mobile Apps Must Die”というラディカルなタイトルだが、筆者は大いに共感でき、多大なインスピレーションを受けた。本稿では、同氏の論旨に依拠しつつ、アプリ環境の今後を展望する。 「アプリの海」 現在、AppleのApp Storeでは50万以上、Google Play（旧Android Market）では40万以上のアプリが提供されており、この数は日々増加を続けている。これらに加え、Window
最強のIT系かあちゃんからたかしへのアドバイス
バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかったです。でも、このシステムを使う人にどういうメリットがあるか分かりませんでした。
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
モバゲーのDeNAのクローズドなオープンソースが話題に
DeNA @DeNAPR 「Arctic.js」のライセンスをMITライセンスに変更し、併せてプレスリリース内容も修正しました。http://t.co/MagzYFpB
いち早く70%〜80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 - 肉とビールとパンケーキ by @sotarok
去年の年末、Facebookで以下の様な画像が流れてきて自分もついついシェアしたんだけど、久々に、というか、自分にとってのここ最近の課題をドンピシャで突かれたような気がして、しばらく頭から離れなかった。 出展: 中村 修治 - 中村 修治さんの写真アルバム | Facebook 「プロ」か「アマチュア」か、というのはこの際どうでも良くて、この図の、上の曲線が、目指すべきところだなって話なだけなので、とりあえずその話をまとめてみることにする。 けど、まぁ、だいたい、こういう話をまとめるのは苦手だし途中で面倒になってしまうので、以下サブセクションだけ先に作ってみたものの、ちゃんと書くかどうかわからない... が、まあ、いい！あと、なんかグダグダ書いてしまいそうだけど、結局、サブセクションのタイトルにしたことをこねくりまわしているだけです。 作ってみるまでわからない 何にも言えることだけど作って
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
今更ですがiOSアプリ開発の基礎について色々調べてみました - もとまか日記Ｚ
最近、以下のような記事を不定期に書いているわけですが。 iPhoneアプリを作ってみよう（Xcode4編）第１回：じゃんけんゲーム iPhoneアプリを作ってみよう（Xcode4編）第２回：簡単ブラウザ そういえば、iOSアプリの開発の基礎的なことって、ちゃんと書いてなかったような・・・・？(^^;;; てなことを考えてた時にTwitterでXcode関連の開発本について、「どの本がいいですか？」的な質問を受けたりもしました。 そこで、大型連休にiOSアプリの開発の勉強をしたい！という方もいらっしゃるかもしれないし？、ってことで、iOSアプリ開発の「基礎」について、色々調べてまとめてみました。 iOSアプリ開発に必須なもの まず、開発環境として必要なのが以下。・Mac・XcodeMacは最近のものであれば、どの機種でも問題ありません。ちなみに私はサンタさんに頂いたMacBook Airの1
プログラマを目指す人が本を読む前に読むべきネットの記事 - もとまか日記
最近、プログラマ向けの書籍を紹介するのが流行ってたようで。 全てのプログラマが読むべき本ベスト10冊見習いプログラマが読んだら、すぐにジョブレベルが上がる１０冊見習いプログラマが読んでも、ほとんど無意味な10冊きれいなソースコードを書くために読んでおくべき本10冊 - ひがやすを blogPythonのプログラマを志したおいらが買ってよかった5冊の本 「プログラマ向けの書籍」という点で言えば、確かにこれらの本を読むといいのかもしれません。ちなみに私はどれも読んだことないです。スミマセン。 ただ、一つだけ気になったのが、これからプログラムを始めて、アプリを作ってみようと志してる方が、これらの記事を読んだ時に果たしてどう思うんだろ？ってことでした。 「こんな高価で難しそうな本を読まないといけないの・・・？」 とか、思ってしまわないだろうか、と。もちろん、そういう趣旨の記事ではないのは分かってる
「売れる iPhone アプリ」にするための151のヒント。 | AppBank
こんにちは、もとまか（@motomaka）といいます。 色々とiPhoneアプリ作ってます。iPadアプリも作ってます。ブログもやってます。どうぞよろしくお願いします。 最近、アプリ開発のセミナー等をよく見かけますね。 ASCII.jp：AppBankが語る「売れるiPhoneアプリとは？」 売れるiPad/iPhoneアプリのためのデザイン必須知識（1/5） – ＠IT 売れるiPhone/iPadアプリの作り方・育て方@銀座 : ATND Togetter – まとめ「第1回iPhoneアプリ勉強会（Presented by AppBank）」 Togetter – まとめ「7/9 #appbank 第2回iPhoneアプリ勉強会」 Togetter – まとめ「7/9 #appbank 第2回iPhoneアプリ勉強会 / 狩られ道さんのターン」 やはり、iPhoneアプリの開発は盛り
個人で作ったWebサービスの仕様書（Evernoteのメモ）を2つ公開してみる - アインシュタインの電話番号
個人でWebサービスを作る際の考察に関する以下の記事が、とても興味深く面白かった。ここに書いてあることはだいたい同意で、自分も実践したいと思うことばかり。 個人でWebサービスを超高速でつくる人たちの作り方を考察。 │ モノづくりブログ 株式会社8bitのスタッフブログです で、記事の最後に執筆者が聞いてみたいこととして「個人Webサービスの場合、仕様書はどうしてるの？」と呼びかけていたので、僭越ながら自分が過去に作ったWebサービスの仕様書（Evernoteに書いたメモ）を公開してみる。公開するのはNekostagramとはてなスターカウンターのもの。 仕様書（TODOリスト）の書き方 自分の場合、Webサービスを作るときに書くものは「仕様書」などと呼べるようなちゃんとしたシロモノではなく、Evernoteに思いついたことをどんどんリストアップしていくだけ。いわゆるTODOリストですね。
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
iPhoneアプリを作ってみよう：目次エントリー - もとまか日記
Amazon.co.jp: 成功する要求仕様 失敗する要求仕様: アラン・M・デービス (著), 萩本順三 (読み手), 安井昌男 (読み手), 高嶋優子 (翻訳): 本
