プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
[iOS] Xcode 6.3 から Objective-C でも Swift の Optional と同等の機能が利用できるようになりました | DevelopersIO
Objective-C でも Optional Xcode 6.3 で Objective-C の言語機能のアップデートがあり、 Optional と同等の機能を提供する __nullable と __nonnull が利用できるようになりました。端的に言うと Objective-C で値が空の状態がより明確に表現できるようになったということです。今回は、この機能をご紹介します。 Xcode 6.3 から利用可能 __nullable __nonnullで定義 nullable nonnull でも記述可能 __nullable と __nonnull __nullable は、NULL または nil が含まれる可能性がある場合に使用します。一方 __nonnull は NULL または nil が含まれる可能性がない場合(つまり、絶対に空ではない場合)に使用します。これらを使うと、例え
![[iOS] Xcode 6.3 から Objective-C でも Swift の Optional と同等の機能が利用できるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b3323f16a41baa5010c4386d0f831ba8c2bd749c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F09%2Fios1.png)
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
Crashlytics から Bugsnag へ移行したお話
Bugsnag という Crash レポート解析サービスがあるんですが、最近 Crashlytics から乗り換えたので、なぜ変えたのかをツラツラと書いていこうかなと思います。 実際 Bugsnag じゃなくてもこのような機能があるサービスの方が個人的には使い勝手がいいかなと思います。 Bugsnag は$29/monthかかります なぜ Crashlytics から移行しようとしたのか Crashlytics は便利なんでずっと使ってるんですけど、 Crash した場合にしかレポートを送信することができないのが一番の不満(※Fabric で改善されているかもしれません) このあとに言及しますが、Social.framework 等を利用した場合のエラーを集めたかったんですけど、そのために Crash しないといけないとか、ありえませんし。なのでそれを取得するために自分でエラー情報を集めよ
UIデザイナー不要説 / LSD LAB
2014/10/26 UIデザイナー不要説 最近UIについてもやもやしていることがあるので書く。間違った知識もあるかもしれない。 先日UI CrunchというUIの勉強会のようなものが開催され、僕はschooの動画配信を見ていたのだが、どうも根底に「UIデザインの重要性が日本では認知されていない」という共通認識が流れているように思える発表が多かった。デザイナー生存戦略やエンジニアとうまく付き合う方法等…。 僕も前のブログ(UID Lab)でそのようなことを訴えてきたので、あぁ、やっぱりみんな不安なんだなあと思ったが、逆説的に「僕らデザイナーが信じているUIデザインの価値なんて、本当は虚像なんじゃないか？」ということを疑ってみたい。 そもそも、なぜみんな「UIデザインが重要視されていない」と感じるのだろう？自分が日頃感じることを列挙してみる。 UIデザインが重要視されていないと思う理由 1.
「Swift」を数週間いじった、その後の評価--発表時の考えを改めた開発者も
「Mac」と「iOS」の開発者が「Swift」を綿密に検証している。Swiftは6月にサンフランシスコで開催されたWWDCでAppleが発表した新しいプログラミング言語だ。真っ先に提起された質問には、次のようなものがある。Swiftは良いものなのか、それとも悪いものなのか。現在と将来のプロジェクトにはSwiftを使うべきなのか。プログラマーは過去に遡って、「Objective-C」で記述したプログラムをコーディングし直すべきなのか。 MicrosoftのMS「Office for Mac」および「Office for iPad」チームのDavid Owens氏はかつて、Mediumへの投稿の中で、Swiftの発表はObjective-Cプログラマーにとって不運だと述べている。 Swiftの発表を受けて、私はiOSと「OS X」の開発の未来をとても悲観している。私の見る限り、Swiftによっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アーキテクチャ、技術、そしてアンチパターン「溶岩流」
ユーザーインターフェイスのデザインのヒント - Apple Developer