新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
2011年6月10日、Evernoteを使用開始。 2014年9月19日、有料プランに加入。 2024年3月23日、クソみたいなメールが届く。 プラン、廃止 いつも Evernote をご利用いただき、ありがとうございます。このたびは今後の Evernote 登録プランに関する変更についてご案内させていただきます。 お使いの Evernote アカウントは Plus から Personal に移行されました。Evernote Plus など、一般のお客様に数年間ご利用いただけなかった従来の登録プランが廃止となったためです。この変更により、Personal プランで利用可能な機能すべてをご利用いただけます。 今後はAnnualの登録プランが現在の Evernote Personal プランの料金 129.99 USD/Yearに合うように更新されます。この料金は次の更新日である2024/4/
電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100％の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。 なぜ判決が覆ったのか、裁判資料かと判決文から見ていく。旭川医大とNTT東は日経コンピュータの取材に「コメントできない」と回答した。 高裁もユーザーの義務違反を認定 旭川医大は2008年8月に病院情報管理システムの刷新を企画し、要求仕様書を基に入札を実施。NTT東が落札した。日本IBMと共同開発したパッケージソフトをカスタマイズし、6年リースで提供
Suicaの凄さ サービスを落とさないための「自立分散高速処理技術！」 ものすごい処理量をこなす緻密な速度改善 お金を扱うからこそ間違わない仕組み 当時は最先端の非接触ICカードを採用 非接触ICカードの歴史 年寄りも当たり前に使えるサービス だからSuicaは６０００万枚も普及した まとめ Suicaの凄さ ものすごい処理量（1日4000万件） 全然サービスが落ちない 年寄りも使っている Suicaがない社会なんて今や想像できないですよね？東京でSuica持ってない人はいないくらい普及していますし、レストランやコンビニでSuicaを使って買える場所も普通になってきました。普通に考えて、1日4000万件も処理して0.1秒以内に処理を完了させないといけないシステムなんて無茶苦茶難しくないですか？しかも、Suicaがリリースされたのは2001年です！ちょこっと調べてみたすごいブレークスルーの数
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。 内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているか。 少し前の講演だけど、ハッカーを目指す上で非常に参考になった。 ハッカーの特徴 ハッカーとは Hacker ethic ハッカーのソフトウェアの作り方 ハッカーの開発スタイル 手順 要求仕様 設計 実装 テスト デバッグ チューニング ハッカーに近づくには 必要な知識 知識の習得の仕方 ハッカーと仕事をするときの問題点 その他に紹介されていた書籍 感想 参考 ハッカーの特徴 普通の人をはるかに上回る高い生産性 高品質のソフトウェアを作りだす ハッカーとは ハッカーズ大辞典によると、 プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求した
[記事移転済]WordPressサイトを構築するといくらかかる？ 見積り勉強会で価格を出してみた | WordBench
はじめまして。このようなやり方の勉強会では以下の理由により意味がないと思います。 ・依頼主の予算感や運用に対する具体的な数字がでていない ・依頼主とのすり合わせができていない ・案件を段階的に進める事が想定されていない 見積は依頼の背景がクリアになって初めて価格の適正が評価可能になりますので、本件のようなスタンスで”典型的なWordPressサイトの見積りでも現状はまだまだ標準的な見積手法が確立されていないことが分かります”とコメントしてしまうのは「無限に広がる土地に家を建てるならこんな設計」って提案を複数並べて「いやー予算と間取りがバラつきましたね。これはまだ建築設計に標準的な工法が無いことを示しています」とコメントしてしまうことと同意で、見積金額がばらつくのは自明です。 また、金額の多寡は状況に依存しますので普遍的に評価することは難しいと思います。逆説的に言えば平均的な価格よりも多少高
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
体力のある大企業と違って、フリーランスや零細企業だと、「ダメな仕事」を受けてしまうと命取りだ。 もちろん戦略的タダ働きというのもあるのだが、体力がない身ではそれは限界があることを知っておくべきだ。 と共に、そういった仕事を避けることも考えておかなければならない。 弊社はSIを積極的に受けているわけではないが、背に腹は代えられない。お金が厳しくなれば、SIだってホイホイやってしまう。 とは言え、何でもかんでも引き受けていると、身動きが取れなくなってしまう。それでは自分も困るし、お客にも迷惑がかかる。場合によっては、業界に迷惑をかけてしまうことだってある。だいたい、原価割れでも仕事は仕事なんで、そーゆー仕事で苦労している間に、もっと率のいい仕事が目の前を通り過ぎて行かないとも限らない。原価割れの仕事は、 海水で渇きをいやす ようなもので、その瞬間は何とかなっても、さらに厳しくなってしまう。 そ
はじめに もともとふつうのベンチャーでしたが、2014年に量子コンピュータにピボットしてからはすくすく会社が育ち、向いてることをするのは大事だなと感じてます。 Qiitaはポエムを書かないといけないらしい（多分）ので。おそらく日本初の量子コンピュータベンチャーとしてまず五年目までに気づいたことを書いてみます。 もともとはデザイン会社 もともとうちの会社はデザイン会社でした。出身が建築事務所だったので、そのまま2009年に独立してデザインをしてました。建築時代はphotoshop+autocadを使っていました。イラレはいまだに苦手です。 前の建築事務所は隈研吾建築事務所というところで、青山の美術館の設計や中国のアリババの社屋のコンペなどを主にしていました。 建築は当時CGパースも仕事がたくさんありましたので、CGのモデリングやレンダリングをやりながら当初は生計を立てていました。ただ、リーマ
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場
「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
今回は高校生の私たちが公開した投票サイトが三日で１万PVを記録したので、その経緯をサイトの紹介も含め、全て公開します。 qiitaで後日談を書きましたので、よかったらお読みください リンクはこちらです サイトの内容 名前はAICEVOTE(アイスボート) リンクはこちら ----> aicevote.com(大量アクセスで現在サーバーが不安定な状況です。ご了承ください。) このサイトを一言で言うとこんな感じです。 "投票用紙を氷に見立てた次世代のリアルタイム投票サイト" AICEVOTEとは 普通の投票とAICEVOTE（アイスボート）の違い 普通の投票 普通の投票では、投票箱A/Bに最終的に投票された票の数の比で結果が決まります AICEVOTE AICEVOTEでは投票用紙の代わりに氷を投票します。 それぞれの投票箱の底は網目になっています 時間が経てばあなたが投票した氷は少しずつ溶け
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介 - 分裂勘違い君劇場
あなたは、日本依存症にかかっていませんか？ 日本依存症とは、日本でしか仕事を得られず、 日本でしか生活ができなくなる、危険な病気です。 日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。 会社依存症の恐ろしさとその回避策 会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。 会社依存症にかかると、その会社の経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。 また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。 上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くの
本当に良いものかどうかは、時間が経たないと分からない。 だから今になって2021年に買って良かったものを紹介する。 Amazonブラックフライデーはこれを買え。 1年が経過した 去年こんな記事を書いた。 本当に良いものは、使い続けることができるものである。そう考えているので「今年買ってよかったもの」が紹介されるこの時期に、あえて「去年買ったもの」を紹介したわけだ。 今年も同じである。今回は2021年に買って良かったものを紹介する。 CO2モニター まずは単体で記事にしたCO2モニターである。 カスタム (CUSTOM) CO2モニター CO2-mini カスタム(Custom)Amazon 細かい話は記事を読んでもらいたいが、人は二酸化炭素濃度が高いと生産性が落ち、さらに高くなると健康への影響も出る。適正値の目安としては以下を参考にすると良い。 400 ppm：外気の二酸化炭素濃度がだいた
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
記者という職業柄、これまで非常に多くのプレゼンテーションを見てきたが、プレゼンテーションの1枚目が半裸の女性モデルの写真だったのは初めてだった。 2月13日、14日の予定で東京・目黒で開催中の「デベロッパーズ・サミット2008」で講演したFog Creek Softwareの創業者でCEOのジョエル・スポルスキー（Joel Spolsky）氏のプレゼンテーション「Joel on Developers Summit――素晴らしいソフトウェアを作るということ」は、型破りに楽しく、なおかつソフトウェア開発者にとって示唆に富む内容だった。 スポルスキー氏は米マイクロソフトのExcelチームで、Excel用マクロ言語を、後にVBAと呼ばれることになるモダンなオブジェクト指向言語に置き換える仕事でプログラムマネージャを務めたことがあるなどソフトウェア開発のベテランだが、エッセイの書き手としても名を馳せ
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
初心者Webアプリケーション開発者がチェックすべき情報源を集めてみた。他に追加した方が良い情報源があった場合はご指摘いただけると助かります。 @ikepyonさんのご指摘により「LASDEC ウェブ健康診断」を追記した。 はてなブックマークの関連リンクによさそうな情報源があったので追記しました。それから、カテゴリを作りました。 ■Webサイト構築 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html 安全なウェブサイトの作り方(全92ページ、2.09MB） セキュリティ実装 チェックリスト（Excel形式、33KB） 安全なSQLの呼び出し方（全40ページ、714KB） ■Webアプリケーション開発 セキュア・プログラミング講座 http://www.ipa.go.jp/security/awareness/ve
毎年恒例の診断前準備として開発者向けに、「初心者Webアプリケーション開発者がチェックすべき情報源」を集めているので、皆さんにもご紹介。他に追加した方が良い情報源があった場合はご指摘いただけると助かります。 上から重要な順。★がとりあえず読んどけ、の必須。必須のポイントは、短期間で大雑把に網羅的にポイントが整理されているもの。 徳丸本を必須に入れるか迷ったけど、あの厚さは、万人は読めないので、上位ランクだけど必須からははずした。 ★Webサイト構築 安全なウェブサイトの作り方 改訂第5版 http://www.ipa.go.jp/security/vuln/websecurity.html 携帯ウェブサイトの実装方法を追加 セキュリティ実装 チェックリスト（Excel形式、33KB） 安全なSQLの呼び出し方（全40ページ、714KB） ★発注仕様 発注者のためのWebシステム／Webアプ
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ
Kaizen Platform, Inc. エンジニア行動指針
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦
アプリ開発費用の内訳 アプリ開発費用は100万円から2,000万円以上の範囲があり、アプリの開発期間や開発工数、エンジニアの人件費に応じて価格に影響します。以下はそれらが分かりやすいよう大きく3つに分類しました。具体的にアプリの開発期間や開発工数、エンジニアの人件費の内訳などの算出方法を解説します。 １．開発期間・開発工数 具体的には、開発の要件が決定した時点で大まかにインフラ設計、管理画面やAPIの実装、単体テスト、検収、審査などを行います。アプリに実装する機能が増えれば増えるほど開発は複雑になっていき、そこに費やす人件費と開発期間が変わっていくという仕組みです。 以下は、標準のアプリ開発をイメージした開発工数となっています。シンプルなアプリ開発を行う場合、ここから作業を削ったり、作業期間を短くしたり、ASPやモジュールを利用したりして開発期間を短縮し、費用を抑えることができます。 ２．
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
スマホアプリを新規作成したらいくらかかる？モバイル見積もり勉強会 #モバイル見積 http://www.zusaar.com/event/3147004 カレー屋チェーン店「ペッパー警部」の公式アプリを作ってほしい、という仮想案件に対して見積もりをしてみる勉強会を2014.01.24 19:00-21:30で開催しました。会場は渋谷の21cafeをお借りしましたが、無料で借りていいの？というぐらいにはプロジェクタ・WiFi完備でキレイなとこでした、同業（？）の皆様にはオススメしておきます。 WordBench神戸勉強会さんの WordPressサイトを構築するといくらかかる？ 見積り勉強会で価格を出してみた http://wordbench.org/2014/01/14/wordbench-kobe/ が、面白かったので、そのスマホアプリ版をやってみた、という話です。 モバイル見積もり勉強
ここでいうおじさんSEとは、主にSIerに生息する、 ・30歳以上で ・モダンな技術を知らない ・レガシーな技術しか知らない ・主に設計書などのドキュメント類を弄っており、コーディングをしない ・現状から変わる気がない（キャリアアップに対し具体的なアクションがない） 人たちを指す。 決して単に妙齢のエンジニアを一括りにしているわけではない。 「おじさんSE」より良い呼び方があれば、ぜひご提案いただきたい。 第1章 おじさんSEの仕事内容 おじさんSEは、コードを書くことはほぼ無い。 これは現場にもよるので、全く無いというわけではないが、 多くのおじさんSEはコーディングはしない。 ではおじさんSEは何をやっているのかというと、 ・内部設計書、外部設計書、詳細設計書の記述 ・結合試験以降の試験項目票の作成 ・試験結果のレビュー 大抵はこの3つになる。 99.9％はウォーターフォール型である。
システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・2021/04/16：文章術系にリンクを追加しました。 ・2020/11/28：文章術系にリンクを追加しました。 ・2020/07/24：文章術系にリンクを追加しました。 ・2020/05/24：文章術系にリンクを追加しました。 ・2020/05/14：スライドデザイン系にリンクを追加しました。 ・2020/04/29：スライドデザイン系にリンクを追加しました。 ・2020/04/17：文章術系にリンクを追加しました。 ・2020/04/12：関連するTwit
いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの？老害なの？」 とか言わないで欲しい。この問題、本当に難しいんだよ！ ■ １度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり
テスト分析・テスト設計入門
© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会（ASTER） 理事 JaSST東京実行委員（2003年～） 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員（2006～） テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長（2011年～） Wモデル研究会 主査（2011年7月～） 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員（20
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
初心者Webアプリケーション開発者がチェックすべき情報源2012 - ハニーポッターの部屋
毎年恒例の診断前準備として開発者向けに、「初心者Webアプリケーション開発者がチェックすべき情報源」を集めているので、皆さんにもご紹介。他に追加した方が良い情報源があった場合はご指摘いただけると助かります。 上から重要な順。★がとりあえず読んどけ、の必須。必須のポイントは、短期間で大雑把に網羅的にポイントが整理されているもの。 徳丸本は今年は必須かな。電子書籍版もあるから、スマホに常備できるし。 あと、後半、まったく初心者向けじゃないけど、セキュリティキャンプ生向けにWebテストできるためのツール類を紹介。Webセキュリティ組の参考に、あと、ネットワークセキュリティ組もFiddler2を使うのはパケットの中身の可視化に良いと思うので、インストールして見られるのがよろしいかと。ここはツール情報を定期的にポストしようと思うので、キャンプ生はチェックしておいて欲しい。 ★Webサイト構築 安全な
僕は日本でも有数の大企業で、ソフトエンジニアというポジションで仕事をしているが、もう転職をしたほうがいいんじゃないかと考え始めている。 元々、僕は大学を卒業後、ある中小のメーカーに就職した。そこではソフトエンジニアが企画の段階から入り込んで、まず商品企画から出てきた機能のプロトタイプを作り（コードは当然自分で書く）、そのプロトタイプを会議に持ち込んで、この機能はいいか、もっとこうすればいいんじゃないかという議論の上、プロトタイプを作り直しては企画を練り直し、最終商品としてリリースするというのが当たり前の時代を過ごした。要求仕様を確定する前に、プロトタイプを何度も作り、ブラッシュアップするスタイルで仕事をしてきた。それがソフトエンジニアの当たり前の姿だと思っていた。 そこから僕はその仕事をする中で、大企業だったら、もっと高度な制御を行うソフトを書ける人が沢山いて、自分もさらに難しい課題を解く
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
最近、私のまわりの会社は求人難だと言う。まともなスキルをもっている人は給料の高い会社(いまならソーシャルゲーム系か)に転職してしまうので、もはや求人市場にはカスしか残っていないとその経営者たちは言う。 毎日、毎日、何十人も面接するが、とんでもないレベルの奴らが大挙して押し寄せてくる。プログラミング歴2年とか3年ぐらいの奴ら。純粋にプログラミングの勉強に費やした時間数で言うと500時間とか1000時間とかその程度の。ピアノで言ったらバイエルすら終わってないレベル。そんな奴らがほとんどだと彼らは言う。 ピアノのリサイタルで金取って演奏するのに、バイエルレベルの奴が来たらブーイングの嵐で金返せーって誰でも思うだろう。しかし、IT業界に至っては最近は開発環境が整っているので生産性が高く、そのレベルの人たちでも出来る仕事がなくもない。だからそんな無茶苦茶がまかり通っているのだ。 私は先日、CODE
ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中！すべてのソフトウェアアーキテクトにおすすめの本がウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない本質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の本当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新人の方によく展開している有益な情報 - Qiita
さようなら、全てのエヴァーノート - 本しゃぶり
失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
Suicaのシステムがいかにすごいか仕組みを徹底解説 - 炎と硝煙にむせる開発現場から
SQLインジェクション対策もれの責任を開発会社に問う判決
コードレビューの目的と考え方 - osa_k’s diary
Googleエンジニアから学ぶ、ハッカーになるための勉強法 - 久保清隆のブログ
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
ダメな仕事を受けないためのNGワード | おごちゃんの雑文
量子コンピュータエンジニア始めて5年が経った - Qiita
高校生がリアルタイム投票サイトを公開したらいきなり1万PVを記録した話 - Qiita
些末なコードレビュー - naoyaのはてなダイアリー
2021年に買って今も使い続けている良かったもの5選 - 本しゃぶり
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
すばらしいソフトを作るには、カリスマが講演 ― ＠IT
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
初心者Webアプリケーション開発者がチェックすべき情報源 - ハニーポッターの部屋
初心者Webアプリケーション開発者がチェックすべき情報源2011 - ハニーポッターの部屋
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
Android案件を見積もる場合に考えておくことリスト - Qiita
実際いくらかかるの？アプリ開発を依頼した場合の開発費用について｜モバイルマーケティング研究所｜モジュールアップス
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
カレー屋チェーン店公式アプリの仮想案件をみんなで見積もってみた #モバイル見積 - ReDo
SIerに生息する「おじさんSE」の生態を知る - Qiita
ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)
日本の大企業のソフトエンジニアはコードを書けない人だらけ
世間ではプログラマが足りていないらしい - やねうらおブログ(移転しました)
ソフトウェアアーキテクトが知るべき97のこと