動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
Í×·ïÄêµÁ¡¦´ðËÜÀß·× - µ»½Ñ¾ðÊóWiki
´ðËÜÀß·× † ¥·¥¹¥Æ¥à¤Î¥ê¥×¥ì¡¼¥¹°Æ·ï¤¬ºÇ¤â´í¸±¤ÊÍýͳ 2008.2.24 ±¿ÍѤ·¤Æ¤¤¤¯¤¦¤Á¤Ë¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤äµ¡Ç½Äɲäǡ¢¶²Îµ¤Î¤è¤¦¤ËÇϼ¯¤Ç¤«¤¯¤Ê¤Ã¤¿Ãæ¿È¤Ï¡¢ºÇ¿·¤Î¥ª¥Ö¥¸¥§¥¯¥È»Ø¸þ¸À¸ì¤Ç¡¢Æ±¤¸¤è¤¦¤Ë¤¿¤¯¤µ¤ó¤Î¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½Å¤Í¤ÆÀѤ߾夲¤¿¤â¤Î¤ËÊѤï¤ë¡£ Ʊ¤¸¥½¡¼¥¹¥³¡¼¥É¤ÎÃÇÊҤϰì¤Ä¤â¤Ê¤¤¤Ï¤º¡£ ¥×¥í¥°¥é¥à¤ÎÊݼéÀ¤ä°Ü¿¢À¡¢ºÆÍøÍÑÀ¤¬¡¢¤É¤Î»þÂå¤Ë¤Ê¤Ã¤Æ¤â¡¢¸À¸ì¤¬¤¤¤¯¤éȯŸ¤·¤Æ¤âÆñ¤·¤¤¤³¤È¡£ Æä˺ÆÍøÍÑÀ¤Ï¡¢¤½¤Î¥
要件と機能を簡潔に伝えるテンプレート
基本設計で使用するドキュメント 「第1回：要件と機能の関連を保つテンプレート（http://www.thinkit.co.jp/article/140/1/）」では、上流工程のうち要件定義フェーズで使用するドキュメントとして、「DUNGEON」テンプレートの中から「要件一覧」と「機能一覧」を紹介しました。今回は基本設計フェーズでのドキュメントについて、ダウンロード可能なテンプレートファイルを元に紹介していきたいと思います。 なお、基本設計で作成する全成果物とその作成手順については、連載「即活用！業務システムの開発ドキュメント標準化（http://www.thinkit.co.jp/free/project/4/1/1.html）」の第3回（http://www.thinkit.co.jp/free/project/4/3/）に詳しいのでそちらを参照してください。 ここで、注意するポイントが
Javaプログラムの設計をテストするツールArchitecture Rules 2.0.3 - builder by ZDNet Japan
デジタル時代のITインフラ構築術 仮想化統合、クラウドを経て今「マルチ」へ ITインフラの最適化と継続的進化への道筋 結果に差がつくウェビナーへの投資 デジタル営業時代における見込み顧客獲得へ ウェビナーの運用・集客・フォローの最適化 体験から学んだ成功への知見 マネーフォワード×エム・フィールド対談 Fintechプラットフォーム開発の「鍵」 ITインフラ運用からの解放 HCI＋JP1による統合運用による負荷激減で 次世代IT部門への役割変革へ一歩前進 特集：IT最適化への道 成功の秘訣をその道のプロが解説 カギとなるのはシステムの「見える化」 アプリケーションモダナイズ 求められている背景にあるビジネスの今 そして、成功の鍵を握るDevOpsの真の意味 さあ、その想いをカタチにしよう。 Google Cloud が企業の未来に向けた生産性 向上とコラボレーション実現のヒントを解説 サー
Excelからプログラムを作る多言語対応オープンソース（1/4）―＠IT
ソースコード自動生成の黒歴史を塗り替えるブランコ Excelからプログラムを作る多言語対応オープンソース NTTデータ ビジネスブレインズ 伊賀敏樹 2007/12/25 開発現場の夢をかなえるブランコ ソフトウェア開発をしていて、「設計書を書き終わったら、そのままソースコードができちゃったらいいな」なんて思ったことはありませんか？ この記事では、まさに「設計書（Excelブック形式）からソースコードを自動生成」してしまう「blanco Framework」（Sourceforgeのページ）というツールの紹介をします。 blanco Frameworkが提供しているExcel様式に、Microsoft Office（Excel）やOpenOffice.orgを使って所定の必要項目を記入すると、Java、.NET、JavaScript、PHP、Ruby、Pythonのソースコードが自動生成で
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
[設計編]ユースケースに詳細を書いてはいけない
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
![[設計編]ユースケースに詳細を書いてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
[ThinkIT] 第2回：見積もり〜設計フェーズで重要なポイント (1/3)
今回は1〜4の項目について、それぞれのフェーズにおける「便利なツール」と注意点を述べるとともに、解説を行っていきます。 5以降のフェーズについては、次回に解説します。 「案件見積もり」のフェーズは筆者としては9つのフェーズの中で、1、2を争う重要なポイントだと考えています。特に「原価や納期も管理して、予定通りに収めなければならない」ミッションを達成するためには、非常に重要だといえるでしょう。 この見積もりフェーズでは、一般的にお客様から頂くRFPや自社営業サイドからの情報を基に、機能一覧法（積み上げ式）などの見積もり手法を用いて工数などを算出し、見積もり担当者 → 部門稟議 → 見積もりワーキンググループ → 最終決済などを経て、お客様にできるだけ早く、かつ可能な限り精度の高い見積もりを出すことが目的となります。 また、工数算出と同時に、想定納期を提出することもあります。精度の高い見積もり
Eclipse Europaでエンジニアリング・ワークショップ - TOPCASED 1.0.0登場 | エンタープライズ | マイコミジャーナル
6日(米国時間)、TOPCASEDの最新版となる「TOPCASED 1.0.0」が公開された。TOPCASED(Toolkit in OPen source for Critical Applications and SystEm Development)は、Eclipseプラグインとして開発されたシステム/ソフトウェア・エンジニアリング・ワークショップ(作業場)。要求定義工程から実装までの作業をサポートするほか、バージョン管理、トレーサビリティ管理、例外事項の管理なども行える。 今回の正式リリースでは、以前のバージョンに比べて、ECORE、UML 2、SysML、structured analysis (SAM)、AADL (Architecture Analysis and Design Language)などに対応したグラフィカルエディタが追加されている。同プロダクトは、もともとEC
Part1 今こそ「基本設計」のスキルを見直す
システムの構造や実装方針を決定し，アプリケーションの機能，データ，画面などを定義する「基本設計」。ITエンジニアの「コア中のコア」と言えるスキルだが，「最近弱体化している」と指摘する声が増えている。今こそすべてのITエンジニアが，ユーザーの高品質，短納期の要求に応えるために，「基本設計」のスキルを改めて見直すべきだ。 「ベテランのエンジニアは基本設計の一般的な手順は理解しているが，高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方，若手エンジニアは実装技術には詳しいものの，肝心の基本設計の基礎的な方法論を理解していないことが多い」――。 こうした悩みは，多くの開発現場に共通する。これは，基本設計そのものが難しくなっているからにほかならない（図1）。 メインフレーム時代は，ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基本設計をこなせた。しかし，システム
システム構築企画や要求仕様のまとめ方：CodeZine
システムを開発する際、「要求仕様文書」をいかにしてまとめるかが成功と失敗の分かれ道であるといえます。なぜなら、「要求仕様文書」によって新システムに盛り込むべき機能をユーザーと開発者の両者が理解できるようになるからです。これが十分でないと、品質、納期、コストの問題にはねかえってきます。 要求仕様をまとめきれないと、その影響は上流工程だけでなく、開発などの下流工程にも現れ、手戻りによる納期遅延やコスト超過などを引き起こします。さらには、システム導入後の品質の低さとして顕在化し、最悪の場合、取引ミスや不具合対応によるコスト増加や業務スピードの低下など、企業に大きなダメージを与えかねません。 最近、システム開発を取り巻く状況が次のように変化してきています。 従来の開発に比べ、期待される開発工期が相対的に短い 要求仕様が固まっていない状態で開発を始めねばならないケースが多い 要求の追加・変更が
「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法：ITpro
上段左からティーアンドエフカンパニー 事業推進統括責任者 情報化戦略コンサルタント 西岡祐弥氏，ティーアンドエフカンパニー 代表取締役社長 佐藤裕司氏，パフ 代表取締役社長 釘崎清秀氏，下段左よりティーアンドエフカンパニー 最高技術責任者 出羽健一氏，パフ 取締役兼株式会社プロシンクワーク代表取締役社長大場京子氏，パフ 事業サポートグループ グループマネージャー 保坂光江氏 Webシステムを開発する際にはほとんどの場合，ユーザーとの打ち合わせのためにHTMLによるモックアップを作る。「このHTMLがそのまま仕様書になれば」と思ったことはないだろうか。就職情報サイトPuffの再構築プロジェクトでは，まさにモックアップをそのまま仕様書した。「十数人の開発者で，5カ月で1000画面のシステムを開発する」必要に迫られたからだ。 HTMLに仕様とメモを埋め込み，CSSで切り替え 「この未体験のスピー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apiary | Platform for API Design, Development & Documentation
ウェブ制作を依頼されたクライアントの、ウェブイメージを簡単にキャッチするための方法*ホームページを作る人のネタ帳
オブジェクト指向開発Tutorial