ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか? 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを100%以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション(PF)」です。 プロジェクトマネジメント(PM)が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド・コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
なんか秘伝のタレみたいになってきたので後世のために共有。 前提 Webアプリケーションを想定 TomcatなりJettyなりがListenするポートは外部からはアクセスできない ※-Xms -Xmx -Xmn あたりは搭載しているメモリ容量によって変える、-XX:MaxPermSize -XX:PermSizeは384mあれば十分だと思うけどロードするクラスの数次第なので要調整。 NOW=`date "+%Y%m%d-%H%M%S"` JAVA_OPTS="-server -Xms2g -Xmx2g -Xmn1g -XX:MaxPermSize=384m -XX:PermSize=384m \ -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=85 -XX:MaxTenuringThreshold=32 \ Javaプログラマーなら習得しておきたい J
色んなシステムに携わっていると、様々なJavaのクラス名に遭遇する。 ○○Beanとか ○○DTOとか ○○Entityとか ○○VOとか ○○Form。 ここらへんって 「MVCのModelのデータ部分にあたるって意味で同じだし」 とか 「ゲッター/セッターがあるクラスで意味的に一緒じゃない?なんで色々名前つけてんの?」 って思いませんか? ってことで、今回はそれぞれの定義を改めて考えてみようと思う。 とりあえずはそれぞれの意味から ・Bean 総称はBean。あえて言うならJavaBeansの略。 Javaの初心者でも知っている。 あまりに有名すぎるが、Oracleのサイトのガイドを見ながらパクってまとめてみた。 ・Sun Microsystems社のJavaBeans仕様に準拠した再使用可能なソフトウェア・コンポーネント。 ・最低限、クラスにはプロパティが必要。 ・プロパティはメソッ
投稿日: 2008年 2月 10日 | 作成者: shiro | カテゴリー: アップル, コマーシャル, 音楽 | Tags: Apple, CM, MacBook Air, Music, Video, Yael Naim |コメントする Yael Naim の「New Soul」は不思議な魅力をたたえた歌だ。 アップルの MacBook Air コマーシャルで大ブレークしてヒットしている。 I’m a new soul I came to this strange world hoping I could learn a bit about how to give and take. 私は新しい魂 この不思議な世界にやってきた 考えをやりとりして 少しでも学べればと思って LyricsMode.com: “Yael Naim – New Soul lyrics“ マニラ封筒から出てこの
2013-09-15 自分で自分の仕事増やして自爆していたらしい もうだめだおうちにかえれない。ぼくはすごいいそがしい。もうだめなんだ。 というわけでなんかもうやたらやること多くて時間なくて明日も朝の7時から店に来なきゃいけないし、しかも事務作業多いからやたらコーヒーとタバコだし体によくないし、タバコ吸うと嗅覚鈍くなるから9年モノと11年モノのにおいの違いわからないしいいことない。 まずですね、自営業者には残業という概念がございません。いくら働いても働かなくてもいいのです。収入が変わってくるだけで。特にコンビニなんてもんは身内の労働で人件費を削って利益を出すようなところがあるまことにヤクザな職業でございますもんで、一定時間は自分でシフト埋めなきゃいけない。そのほかに店の運営に関する業務が被ってくるもんだから、こいつぁもうたまらねえ。 しかしですね。ふと気づいたんですよ。俺なんでこんなやるこ
一方で、Webサービス系などで論理設計と物理設計をもう一緒くたにやっていくような場合は、 正規化の論理に目の前にあるサロゲートキーを含めないようにすることが大切で、モデリングはナチュラルキーを基軸に考えていくとよいでしょう。 サロゲートキー (代理キー) サロゲートキー + (複合)ユニーク制約 ナチュラルキーをPKにせず、例えば連番となるようなカラムを用意して、それをPKにします。 これがサロゲートキーと言われるものですが、ナチュラルキーには別途ユニーク制約を付与する というのを忘れてはいけません。 ここでは、ナチュラルキーにユニーク制約を付けずにサロゲートキーだけを導入する方式は、業務的・実装的に意味はないと考え、ここでは取り扱いません。 議論の対象にすらしません。ユニーク制約を付けることで業務的なユニーク性を保ちつつサロゲートキーの恩恵を得ることができ、同時にナチュラルキーを明示する
テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルAが「社員」で、Cが「趣味」で、ACが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の5つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [A] {a}, b + 100 aaa
先日、データベース設計で、ナチュラルキーの組合せを使った複合主キーと、その代替となるサロゲートキーのどちらを使うか、という話を書きました。 複合主キーを避けるべき理由 - 虎塚 月末までには、改めて考えを整理するつもりでした。しかし、残念ながら、今の自分の知識ではムリそうです。そこで、考えたことを少しずつ出力することにしました。 この問題について考えるべき(だった)こと 前回の記事に足りなかった観点が3つあります。 データベースの論理設計と物理設計を分ける 複数ある要素の一部にだけ言及していると自覚する すべては程度問題である これらを1つずつ考えてみます。 1. 論理設計と物理設計を分ける まず、データベースの論理設計と物理設計を分けて考える必要がありました。非常に、基本的なことですが・・・ 論理設計で、ユニーク制約が必要なキーと、行を一意に特定するキー(候補キー)を特定します。もちろん
資料の羅列だけの割に長くなるので、結論だけ先に書いておきます。 技術・アイデアが枯れたSNSの末路は、集めた個人情報を使ってユーザーには恩恵のない商売に手を出す他に手立てがなくなり、 最後は元よりユーザーに恩恵を与える事に興味が無く集まる個人情報活用に興味がある悪質な業者に中身が入れ替わる。 したがってユーザーは過去にとりあえず…で登録したサービスが、見かけ上存続していることに安心してはいけない。 もし僅かでも(メールアドレスだけでも)リアルな情報を入れているなら、見かけ上存続している状態の運営でも、 その間に登録情報を上書きしてから退会しないと半永久的にリサイクルされる危険がある。 ■前回の記事 主人が「ゆびとま」で「甚大なトラブル」に遭って3週間が過ぎました 彼氏が「ゆびとま」使ってた。別れたい… ■再調査に至る経緯と動機 「この指とまれ」(以下ゆびとま)がヤクザの支配下で破綻、正体の
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン(Multi-Paradigm Design: MPD)の中核を成し、DCI / リーンアーキテクチャ(Lean Architecture)とも深く関係する 共通性/可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
English This website is currently not available. Please try again later. Thank you. Deutsch Diese Internetpräsenz ist zur Zeit nicht erreichbar. Besuchen Sie diese Seite zu einem späteren Zeitpunkt noch einmal. Vielen Dank. Español Esta página web no se encuentra disponible en estos momentos. Por favor, inténtelo de nuevo más tarde.
Twitter APIのJava向けライブラリ『Twitter4J』の開発者として知られる山本裕介さん。個人のエンジニアとして実績をつくる上で「知ったかぶり」が重要だと言う。技術の幅を広げるために少し背伸びして、「限界を決めない」ことを信条とする仕事の哲学・生き方について語ってもらった。 ▼山本裕介氏へのインタビュー第1弾 転職、フリー、起業…いつでも飛びこめる準備を―元Twitter技術アドバイザー山本裕介氏のキャリア論 仕事もプライベートも限界を決めない。 会社の「看板」に依存せず、いつ訪れるかわからない転機に備えて個人として実績をつくる重要性を説くのは、36歳で転職5回、フリーランス、起業を経験したソフトウェアエンジニアの山本裕介さん。 実際、個人で開発したTwitter APIのJava向けライブラリ『Twitter4J』がきっかけでTwitter社にジョインしている。 現在は独立
OSSデベロッパーとして知られ、二児の父でもある山本裕介さんは、4回の転職を経てTwitter社にジョイン。現在は独立し、会社を設立している彼は、この立ち位置をいかに確立したのか。そこには山本さんが実践した「成長のための転職」と「セルフブランディング」にキャリア形成のヒントが隠されていた。 5回の転職、フリーランス、起業…すべての経験を糧に。 日本では未だに「ジョブホッピング」に対して、マイナスのイメージを持たれることは多い。 一方で、年功序列型の給与制度や終身雇用はもはや昔話。これからの時代、いかにキャリアを築いていくべきか。ロールモデルの少ないWEB・IT業界において、そのヒントを探るべく、多くの転職、働き方を経験された山本裕介さんにインタビューした。 山本さんは新卒で国内SIerである新日鉄情報通信システム(現新日鉄住金ソリューションズ)にSEとして入社。その後、ミドルウェアベンダ『
初音ミクとの共演で話題の冨田勲「イーハトーヴ交響曲」初演は、いよいよ来週23日(金)。コンサートの総指揮に当たっている冨田さんご本人に、軽井沢の別荘で3時間にわたるロングインタビューを敢行しました。「初音ミクと宮沢賢治に共通するもの」とセットでお読みください。 日本初のシンセサイザー音楽から「初音ミク」に至るまで 冨田勲といえば、まず日本のシンセサイザーの第一人者である。70年代に多重録音で制作された数々のアルバムは、どれも強烈な印象が残っているし、ジャンルを問わず、世界中の様々なミュージシャンから尊敬を集めてきた。 ただ、初音ミクを聴く若い世代には、当時のムードも含め、そのイメージはつかみにくいかもしれない。そこで、音楽家として活動を始めた頃から、現在に至るまでの歴史を、長年のファンならおなじみのエピソードも交えながら、ざっと振り返っていただいた。 冨田さんは1932年4月生まれ、今年8
▼ [Software]リリースバージョン番号の付け方 ソフトウェアのリリースバージョン番号(「1.2.3」みたいなやつ)の付け方について。ネット上で探してみても「これ」という指標が余り見付からないので、「とりあえずこうしている」という意味でメモっておきます。 それぞれの番号をここではA.B.Cと呼ぶとして、 A(メジャーバージョン) それまでのバージョンと比較して、一部の動作において、後方互換さえも破棄するような大きな変更が含まれる時に繰り上げます。例としては、過去に許されていた一部文法が通らなくなったプログラミング言語Python 2からPython 3への変更などが当てはまります。メジャーバージョンが繰り上がることを「メジャーバージョンアップ」と称するケースが多く、大々的に告知してから移行するのが通常です。また、バージョン番号「1.0.0」を最初の製品レベル品質に達したリリースと位置
最近さまざまなイベントやブログエントリで見かける「DevOps」。この言葉をひもとき、なぜ「Dev」と「Ops」が衝突するのか、その解決に必要な要素とは何かを分かりやすく解説します。 DevOpsとは 2009年にオライリーが開催した「Velocity 2009」というイベントにおいて、Flickrのエンジニアが、“開発と運用が協力することで、1日に10回以上のペースでリリースが可能になること”を紹介しました。いまさまざまなシーンで見かける「DevOps」という言葉は、このプレゼンの中で登場したものです。 DevOpsとは、開発(Development)と運用(Operations)が協力し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。多くの人々により議論は続けられていますが、ITILとは異なり、現時点においては、DevOpsに厳密な
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから(後編)~Salesforce Developer Conference Tokyo 2013 9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法をこれまでの経験や現在の開発現場のノウハウを基に語っています。 試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジニアやデザイナーにとって非常に参考になる内容が込められたセッションの内容を、ダイジェストで紹介しましょう。 (本記事は「伊藤直也氏が語る、モバイルアプリケーショ
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから(前編)~Salesforce Developer Conference Tokyo 2013 いま多くの開発者が取り組もうとしているモバイルアプリケーションの開発は、経験の面でも技術の面でも、コンシューマ向けの開発現場が大きく先行しています。 9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法を、これまでの経験や現在の開発現場で得たノウハウなどを基に語っています。 試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く