いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
New community features for Google Chat and an update on Currents
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
10年後も世界で通じるために - Nothing ventured, nothing gained.
最初、Google+で書いたのだけれども、コメントなどで参考になる話が多く聞けたので、こちらにも展開したい。 木曜日と金曜日に通称デブサミ、Developers Summit 2012に参加した。特定のベンダーや技術にとらわれることなく、広く技術から開発方法論まで話されるこのカンファレンスも今年で10周年だ。関係者の皆様、お疲れ様でした、おめでとうございます、来年からもがんばってください、応援しています。 10周年ということもあり楽しいムードが満載の中、ふと疑問を持ったので、Twitterでつぶやいてしまった。 素朴な疑問なのですが、 #devsumi の「10年後も世界で通じるエンジニアであるために」って現在すでに世界で通じるエンジニアであるという前提ですね？ https://twitter.com/#!/takoratta/status/170341136370638848 このデブサ
［SQEXOC］プロジェクトを失敗させないためには？ スクウェア・エニックスで実施されているプロジェクト管理術公開
［SQEXOC］プロジェクトを失敗させないためには？ スクウェア・エニックスで実施されているプロジェクト管理術公開 編集部：aueki スクウェア・エニックスCTO 橋本善久氏 10月8日，東京・新宿で開催された「スクウェア・エニックス オープンカンファレンス2011」で，同社CTO/テクノロジー推進部担当コーポレートエグゼクティブ 兼 ジェネラルマネージャー/新世代ゲームエンジンLuminous Studio プロデューサー 兼 テクニカルディレクター/リアルタイムテクノロジーデモPhilosophy プロデューサー 兼 総合ディレクター/FINAL FANTASY XIV テクニカルディレクター橋本善久氏によって「ゲーム開発プロジェクトマネジメント講座」と題した講演が行われた。 肩書きからも分かるように橋本氏は，さまざまなプロジェクトを担当している。そんな氏により，スクェア・エニックス
スマホ案件の見積もりについて - ku-sukeのブログ
Android案件の見積り ｜ クラスメソッド開発ブログ を読んで、業界人らしき人のブコメが、「この程度でホッテントリか」という感じで、僕もややそっちよりの意見だったので、ざっくり補足できそうな点について書いて見ました。もう転職して受託の立場ではなくなったので。やや発注側の視点も含まれています。 責任のないリスクについてコスト負担範囲を決める すべてにおいて最重要項目です。変化の激しいスマホ業界においては、互いのリスクテイクについての認識をあわせておく必要があります。例としてはこんなものがあります。 開発期間中に突如OSのメジャーバージョンアップがあった。 顧客「あ、新しいのでましたね。対応できますよね＾＾」 世論に応じて機能の根幹部分が突然リジェクト対象になる。 りんご「今日から電話番号認証禁止ね＾＾直さないと削除しちゃうよ＾＾」 過去を顧みない方針転換がなされる ぐぐる「メニューボタン
開発に必要な力は二つしかない - 神様なんて信じない僕らのために
最近開発をしてきて開発者に重要だと思うのは、 ・問題を発見する力 ・問題を解決する力 の二つだと思っている。 実際にコードが綺麗とか、技術が卓越している、というのは個人の手腕であり、 持ちうるスキルではあるのだけれど、 それは「問題を解決する際に使われる力」だ。 そして、これには「コミュニケーション力」や「交渉力」、 「論理的思考」や、「選択肢の中から成否を見据える力」も含まれている。 そして、これを行うためには「問題を発見する力」が欠かせない。 「何が問題なのか？」を考えずにこれらの力をふるうことはできない。 いかな高い技術力があっても、それを使う場所や使うべき場面が解らなければ何の意味もない。 要するに重要なのは「問題を発見し、解決する力」だ。 これが出来れば職場も個人の問題も、何でも解決できる。 そして、組織が強いのは沢山の眼があること、沢山の思考があること。 要するに重要な力は２つ
技術/組織としてどうスケールするか at GitHub - yaotti's diary
会社をスケールさせていくために組織面，技術面で何を行ってきたか．以下簡単なまとめ 組織面 従業員をよりhappyにするために，面白い仕組みを導入している．ミーティングがない，オフィスに来なくても良い．やりとりはpull requestとcampfire． 他にも組織として強くなるために，個人に依存しすぎない(知識共有を促進する)，internal talk(tech talkみたいなのかな?それとも普通の会話?)は将来の従業員のために全て記録する*1，など． 技術面 自動化可能なことを手作業でやり続けることによるコストは，手間だけではない．新規メンバーに学習コストが発生することになる． masterブランチは常にデプロイ可能な状態に保ち，1日に5~30回デプロイを行なっている． 意味のあるメトリクスをグラフ化しよう．全体でのレスポンスタイム平均がXXXms，というのは意味がない． リリース
本当はすごい codefirst の開発環境 - suer のブログ
(本記事は @suer, @mallowlabs, @mzp がノリノリで共同執筆しました！) 近代的なソフトウェア開発に必要なツールは3つある。 分散バージョン管理ツール ITS CI ツール 私はこれに AsakusaSatellite (以下AS)を加えたいと思う。 以上の4ツールを使用することによって、迅速なコミュニケーション、洗練された自動化をベースとした開発リズムを体験することができる。 このあとの節では具体的なユースケースをベースに、上記ツールの連携方法及びそのメリットをみていく。 ユースケース：開発中にソースコードの特定行で例外が発生した原因を探る ここは codefirst の開発室。 @suer と @mallowlabs と @mzp はリズム良くコードを書いています。 そんなとき、ビルドの異常を知らせるポップアップが表示されます。 さっそくAS 上でミーティングがは
クラウド時代にこそCOBOLなベテランから学ぶこと - 急がば回れ、選ぶなら近道
言うまでもなく、COBOLなベテランは非同期バッチ処理の達人が多い。 日本ではこの手のベテランが多い。 まず世界でも例がないほどだと思う。 クラウド時代はむしろ非同期処理のオンパレードであり、 学ぶべき点はたくさんある。 こと運用レベルや、対障害設計は神レベルの人が多いので まじでノウハウは受け継ぐべし。 個人的に達人系の技のポイントをまとめておく 1.コンテキストを外部から与える 一種のDI的な考え方である。 但し、あくまで運用目線であることが重要。 通常のDIは開発効率を目的に考えていることが多く見受けられるが 非同期処理についてのDI的な考えは運用効率性の重視だ。 対障害設計をする上で、もっとも大事なことは 「コンテキストがまっさきに見えることだ。」 これはDI的は発想とはまるで違う。 今走っている処理は、 ・どういうモノで、 ・何を想定していて、 ・どういうスケジュールになっていて
レベニューシェア注意点:Geekなぺーじ
「1,000万円のサイト構築費を50万円に抑える方法」 という記事がありました。 私が趣味でやっていることは「レベニューシェア」と言うのか！という発見が新鮮でした。 (参考：制作費を受け取らないWebクリエイターは実現可能か？、プレコ専門店とWebサイトを共同制作) 今のところ半年ぐらいやっていますが、何となく思ったところをまとめてみました。 私の視点は、個人もしくは小規模なWeb技術者がレベニューシェアをやってみるという視点です。 Web担当者さんの記事とは恐らく前提が違うので、ご注意下さい。 1. コミュニケーションが重要 レベニューシェアという形態だと、発注と受注のような明確な役割がありません。 極端な言い方をすると、一緒に仲良くやろうという感じです。 (「仲良く」の内容が例えば収入の折半だったりしますがそれは契約や約束次第になります。) そうすると、どちらが意思決定をするかというの
Buzz by Rui Ueyama from Buzz
Lispはなんとなくすごそうというイメージがあるけど、実際にはそれほどでもない。90年代くらいまではGCがあるというだけで、生産性X倍といえたのかもしれないが、いまは良い他の言語がたくさんあって、言語の日常的な使用例で差が特にあるとは思えない。 現代のプログラミングでは充実したライブラリの存在がますます重要になってきている。その点マイナー言語は苦労することが多くて、PythonやJavaでさっさと書けることにすごく時間がかかったりする。プログラミング言語はコンピュータに対する命令であると同時に、ほかのプログラマに読んでもらうための文字通りの言語だ。自分でいろいろ作るのも楽しいけど仕事でどっちを使うかというと、みんなが読み書きできて早く終わる方がいい。 プログラマの費やす労力のうちプログラミング言語そのものにかかっているのは一部にすぎない。プログラミング言語は一番目立つ位置にある――字面その
Working with Apple Services
Working with Apple Services Learn how to integrate Apple Music, App Store, Apple TV, Apple News, Apple Books, Apple Podcasts, and other content into your marketing programs. Identity Guidelines Follow these guidelines on how to use approved badges when promoting Apple’s services in marketing communications. Apple Services Toolboxes Promote content on Apple Books, Apple Music, Apple Podcasts and Ap
上海生活3ヶ月まとめ オフショア開発と中国人と日本人 - 週記くらい(BTS開発記)
free3ヶ月間中国の上海で仕事してきた。元々、ソフトウェア関連業界で働いていたから何度かオフショア開発も経験した。それらの開発は、案の定、迷走し厳しいプロジェクトになった。その時の上司は、賢い人だったので、一つ一つ対策を実施した結果オフショア開発でも炎上しない環境を作り上げることはできた。しかし、その時ですら、日本側での資料作成作業、受入テスト作業、中国側の優秀なエンジニアのアサインなど、多くのコストアップという犠牲を払っていたため、オフショア開発の目的である金銭的なうまみは、ほとんど出ていない状況になっていた。 それまで中国側の開発現場を生で見たことは無かった。多くのオフショア開発の問題点である品質の低下、認識のズレからくる間違った実装などを、どう理解してよいかわからなかった。「中国はだめだ」という結論は、安易すぎるし、あまり利口な考えではないというのは感じていた。その理由というか結論
A shorthand for designing UI flows
Flows are just as important to good interfaces as individual screens are. Customers don’t land on screens from out of nowhere. Specific sequences of actions lead customers through your app as they try to accomplish their tasks. But as important as they are, flows are hard to communicate during the design process. Drawing out every state of a flow is too time-consuming. And drawings become instantl
EC-CUBEはここが酷い。 - zan-gyo’s diary
最近 EC-CUBE のプログラム修正を仕事でしているわけだが、EC-CUBEのプログラムソースは余りにも酷すぎる。 開発者が初歩的な英単語を理解していない。 「check」が「cheek」になっている等、スペルチェックをしていない。 税額を加算する関数がなぜか「sfPreTax」だったりする。加算するのに「Pre」は無いだろう。 開発者が簡単な論理演算ができない。てか変数名のコピペ複写後の名前変更すらきちんとできない。 SQL文で 製品ID が特定の値で、 規格ID1 と 規格ID2 のどちらかがゼロで無い場合。 ×「product_id = ? AND classcategory_id1 <> 0 AND classcategory_id1 <> 0」 ○「product_id = ? AND (classcategory_id1 <> 0 OR classcategory_id2 <
ゆとりiPhoneプログラマの為のメモリ管理 | fladdict
主にFlashのガベコレで脳が弛緩してる、ゆとりiPhoneプログラマ向けのメモリ管理術。しち面倒なRetainCountの管理を30秒で解決するよ。 1:とりあえず NSMutableDictionary を１個作る。このDictionaryはプロパティとして保持する。 2:alloc / init でインスタンスを作るときは、[[[ClassName alloc]init]autorelease] と必ずオートリリースをつける。 3:[NSString stringWith〜] のように、allocとinitを経ずにインスタンスを作る場合は、自分で勝手にretainをしない。 4:作成したインスタンスは持続的に必要な場合、NSMutableDictionary に突っ込む。 5:必要なくなったインスタンスは、NSMutableDictionary から remove する。 こうすると
iPhoneアプリからMyWebClipに連携する方法について - もとまかのiPhone・iPod touch戯れ日記
先日リリースした「ポケット1.2」で、MyWebClipと連携する機能を追加したわけですが、きっと、「自分のアプリもMyWebClipに連携したい！」という方もいらっしゃるのでは？と勝手に思ってます。（そういう質問が私のところに来ているわけではないんですけどねｗ） 連携仕様の開示について、MyWebClip開発者である岸川氏に伺ったところ、非公開にしているわけではなく、ブログで公開する時間がない、とのことでした。 そこで、岸川氏、及び販売元のforYou様に許可を頂きましたので、MyWebClip連携方法について、本エントリで紹介したいと思います。 少しでも、連携の輪が広がっていきますように。 「MyWebClip スキーマ仕様」 MyWebClipのURLスキーマ仕様は以下となります。 ://?# 上記のように、アクションの種類とクエリを指定します。詳細は以下にて。 ■通常版とLite版
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.beyondfactory.net/blog/?p=18
GitHub - sumihiro/ARKitTweetDemo: ARKitDemoを改造してtwitterのTLのアイコンを表示するデモです。TweetFetchDefines.hはTweetFetchDefines_Sample.hを参考にして自身の情報で作成してください。また、ARKitDemoAppDelegate.mに現在地を指定する部分があるので、任意の点に書き換えてください。
