マネジメントに興味がなくても騙されたと思って『エンジニアのためのマネジメントキャリアパス』を読んでくれ - dskst's diary
エンジニアのためのマネジメントキャリアパスという書籍が出版されました。 タイトルに書いたとおり、マネジメントに興味がなくても、読むこと大きな学びをもらえる本です。 及川さんが前書きを書いており 本書を読み終わった後、私はひどく落ち込んでいる自分に気づきました。 ~中略~ 内容が素晴らしい故に、いかに自分が未熟であったかを思い知らされた と、記載があって衝撃を受けました。 及川さんが落ち込んだら、私なんて精神崩壊してしまうのではないか…！？ 本書を読んで、精神崩壊こそしなかったですが、ひどく落ち込みました。自分のレベルの低さを痛感します。 本記事では本書の知識定着のためのアウトプットと、所感をまとめています。各章毎にピックアップして記載します。 書籍の内容 1章 マネジメントの基本 2章 メンタリング 3章 テックリード 4章 人の管理 5章 チームの管理 6章 複数チームの管理 7章 複数
Google Apps Script ハンズオン資料 #GoogleAppsScript
この資料の説明 2018/10/04 に グロービス で行った 第 1 回 Google Apps Script (GAS) ハンズオン @麹町 のハンズオン用資料です。以下の流れに沿ってハンズオンを進めていきます。 手順は細かく書いていますので、社内外で是非流用してください！ ハンズオンは以下の記事の感じで進めました！ チューター少人数でも回せる！Slack を駆使したハンズオン勉強会のやり方 ハンズオンをスムーズに行うために Chrome 推奨 Chrome 拡張の JSONView 入れておくと Good! 意図しないエラー対策 GAS をローカル開発で開発したい方はこちらを参照 ハンズオン用の Slack に JOIN アジェンダ Google Apps Script とは 公式チュートリアル Your first script Gmail to Spreadsheet Form
Using the classic ASP unit test framework
Published: at 8:50 PM on Friday, November 21, 2008 Category: classic asp , tdd Previous: http://www.beingnew.net/2008/11/automating-classic-asp-unit-tests-with.html Next: http://www.beingnew.net/2008/11/london-altnet-beers-night-25th-november.html This is the fifth part of a series on unit testing classic ASP and in this we will start to use the framework to implement our example user stories we d
レジェンドコードと向き合いレガシーからモダンへ変革する | ランサーズ（Lancers）エンジニアブログ
shin ( @nagatashinyalan )です。 先日、BASEさん、ReBuildさん、ランサーズ で、「レガシーコード改革！UT/CIでWebサービスの技術的負債を解消する取り組み」 というイベントを開催し、そこで登壇しましたので資料を公開します。 読んでもらいたい方 技術負債解消施策の失敗/成功事例を知りたい方 レガシーなPHP環境を変えて、前に進みたいと思っている方 レジェンドコードとは何？と思った方 概要 ランサーズの開発の歴史とテスト 創業期(2008-2011) UnitTest, Selenium 成長期(2012-2015) Behat/Mink, テスト自動化プロジェクト(ojido_sun) 変革期(2016-2018) CircleCI, PHP/CakePHPバージョンアップ, レジェンドコード
『レガシーソフトウェア改善ガイド』を読んだ
本書『レガシーソフトウェア改善ガイド』は、タイトルの通り、「レガシー」なソフトウェアをいかにして改善していくか、というテーマの本です。 「レガシー」というと、『レガシーコード改善ガイド（下記書籍）』が思い浮かぶ方もいると思いますが、本書は『レガシーコード改善ガイド』の補完的な位置づけの本であるとみることもできます。 ちなみに、上記2冊はいずれも翔泳社から出ているので、タイトル、装丁ともにシリーズものっぽい感じですが、『レガシーコード改善ガイド』の原書はWorking Effectively With Legacy Code、『レガシーソフトウェア改善ガイド』の原書はRe-engineering Legacy Softwareであり、出版社も異なります。 レガシーなソフトウェアとは 『レガシーコード改善ガイド』では、「テストがないコードはレガシーコードだ」という明快な定義にもとづいて、テスト
「書き直したい」 をグッと抑えて小さな改善を積み重ねよう | Recruit Tech Blog
この記事はRECRUIT MARKETING PARTNERS Advent Calendar 2017の投稿記事です。 こんにちは、2016 年中途入社の nobuoka です。 ソフトウェアエンジニアとしてキッズリーの開発に携わっています。 先日読んだ 『「書き直した方が早い」 は 9 割のケースで間違いだった』 というブログ記事に触発され、最近考えていた 「小さな改善を繰り返すこと」 について書き記します。 意識の話に寄っていて技術的な話ではないですが、是非読んでみてご意見をお寄せいただければと思います。 後半では、実際の製品開発での取り組みも紹介しています。 伝えたいことは一つだけ。 タイトルにある通り 「どうにも手が負えないから新たに書き直したい」 という気持ちに対して、一度それをグッと抑えて小さな改善を積み重ねよう ということです。 背景 : 新しく書き直すか、小さな改善を繰り
レガシーコードとAspectMock | GMOメディア エンジニアブログ
はじめまして、室内ならTシャツで問題ない技術推進室の篠崎です。 先日、piccaglianiさんのブログでAspectMockを知りました。 ちょうど私が対応しようとしていた課題にぴったしのフレームワークだったので少し書かせていただきます。 昔からあるコード弊社では以下のようなコードがまだまだいらっしゃいます。（実際はこんな少ない行数ではありません） がっつしArticle_Query、Apiクラスに依存している状態です。 私が対応しようとしていた課題は「このような昔からあるテストのないコード、いわゆるレガシーコードに対してユニットテスト（PHPUnit）を作成していく」でした。 ※そしてリファクタリングへ ユニットテストで何を確認したいのか？ユニットテストで確認したいのはSample_ServiceクラスのgetAllArticlesメソッドの処理です。 Article_Query::f
Faao - ドメイン駆動設計で作るGitHub Issue Client -
autoscale: true Faao - ドメイン駆動設計で作るGitHub Issue Client - 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 過去に作ったやつ azu/GithubReader: Github Notifications Client for OS X azu/github-reader: [node-webkit] GitHub client app - Viewer for Notifications and News Feed. azu/github-issue-teev: [NW.js] GitHub Issue Manager(Viewer) Faao Faao - Feature Support Modern browser/mobile/Electron(re
モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 概要 DDDの定義についてEric Evansはなんと言っているのか この記事でドメイン駆動開発の定義は以下のようなものであると書きました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す では、ドメインの知識を言語化したモデルは、最終的にコードでどのように表現されるのでしょうか？ 不変条件 まず、業務の制約に
![モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/174d1982a10d2244bf20050a91ace81d3604c05e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F11696248318756265553%2F8599973812304765036%2F1704288106)
ボトムアップドメイン駆動設計 後編
はじめに この記事は続編です。 前編記事: ボトムアップドメイン駆動設計 https://nrslib.com/bottomup-ddd/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 ファクトリ 独自の採番システム ところで UserId は Guid （Globally Unique Identifier）です。 Guid は事実上どこでどのタイミングで生成したとしてもユニークになります。 その性質を利用して User は一意な id をコンストラクタで生成していました。 しかしプロダクトによっては Guid ではなく独自の採番機能を採用したいという事例は往々にしてあります。 そこでデータベースの採番テーブルを利用した独自の採番システムを利用して User オブジェクトをインスタンス化してみましょう。 コンストラクタで SQL を実行して採番していま
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO
こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡 に参加してきたのでレポートします。 当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後について ビッグローブ株式会社 西 秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。 アジェンダ DDD導入に至るまで 導入時の苦労 導入による効果 今後の目標 BIGLOBE販売システムについて、DD
![[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca7afdf4d75f0e7f31dad0cb5f52f15acfa79209/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F09%2FDDD_blue.png)
ドメイン駆動設計ドメインモデルの役割と例 - ネクストデザイン
ドメイン駆動設計とは ドメイン駆動設計は、ドメインモデルの重要性とその役割に焦点を当てたオブジェクト指向の手法です。 アプリケーションの本質はドメインにあるという考えのもと、設計者はドメインに集中してドメインモデルを作成します。 ドメインモデルはドメインの中に存在するオブジェクトの集まりを抽象化したもので、ドメインはシステム化対象領域のことです。 ドメインとドメインの外側 (例えば実装技術など) との境界を明確にして、ドメインモデルを隔離します。 隔離されたドメインモデルをシステムの土台とすることで、実装技術などに左右されず、安全に拡張できるシステムを設計できます。 設計や実装、コミュニケーションなどで登場するすべての概念 (用語やクラス名など) は、ユビキタス言語 (後述) て記述すうることで追跡可能なシステムができます。 ドメイン駆動設計は、ドメインモデルを中心にシステムの洗練と検証を
社内でDDDのコードリーディング会をやりました | mmjテックブログ
モデルでドメイン知識を表現するとは何か[DDD] この記事がすごくいいこと書いてる感じなので、今からDDDに沿った設計をしようと考えてる弊社のプロジェクトメンバーでぜひ共有したい！と思い、コードリーディング会をやってみました。 みんなでコードリーディングすることで、 学習負荷を下げ、(僕が楽するため 🙂 ) 疑問点も即座に質問し合えて理解度も高まり、 得た知見を共有知にできる みたいな効果を目指しました。 やってみた オフィスにいたプログラマ4人で一緒に内容を読み合わせ、悪いコード例、いいコード例について議論しました。 以下のような知見/気づきを得ることができました。 セッターがあるとオブジェクトの状態を変えれてしまうのでよくない。基本セッターがないオブジェクトとしてクラスを設計しよう。 ドメインモデルにドメインの知識を集めることで、得られるもの。 不変条件をコードで表現できるので、プロ
Logicの実装デザイン | LastaFlute
いきなりまとめ 実装デザインの提案 Action は、こちら Logicに何を実装するか？ 再利用するものだけをロジックに！ ルーズなロジックだと？ 二個目が見えてないときは難しい 再利用するときに切り出せばいい No more, アバウトLogic!? No more, Logic が Action 継承!? No more, Logic が WEB に依存!? いきなりまとめ 実装デザインの提案 本気でDDDをやるフェーズまで達していない段階、かつ、プロジェクトで独自にアーキテクチャを定義していない場合の、LastaFlute からのデフォルト実装デザインの提案です。 Action (バウンダリ、かつ、ファサード: Transactionあり) フローコントロール、そして、再利用しない検索や更新など(ちょこっとロジック)を書く WEB依存 "する" 処理の再利用や、ちょこっと役割分担は
社内勉強会でサービスクラスがなぜ存在するのかについて紹介しました - UUUMエンジニアブログ
設計と実装で 抑えておきたい サービスクラスと例外 from Takuya Sato nazoです。 最近はUUUMもエンジニアを含む開発チームもメンバーが増えてきました。メンバーが増えてきた時に、どうしても技術力にムラがある（単純に高い低いという話ではなく、得意な点や考え方が個人により異なるということ）という問題が生じます。 個別の細かい技術についてはその場で説明すれば良いのですが、「設計」と言うと単純に説明するのは難しく、そもそも人によって考え方にも違いがあります。とはいえここは抑えておいてほしいというところはあるので、社内で勉強会を開催して説明した内容を社内向け文書も兼ねて公開したいと思います。 今回は「サービスクラス」の作り方について紹介したいと思います。サービスクラスという概念はバックエンドに限らず、フロントエンドやその他様々なアプリケーションで応用できる概念かと思います。資料に
jQueryからVue.jsに乗り換えて良かった点・悪かった点をまとめてみた！ - クラウドワークス エンジニアブログ
今年の3月からクラウドワークスで働き出した高梨です！ さっそくですが、 最近、jQueryで書いていたJavaScriptをVue.jsに変えていくということをやりました！ 「がっつりcomponent化して、API用意して、SPAにして・・・」 みたいな感じではなく、 最低限jQueryでやっていた表示・非表示の処理だったり、金額を計算するといった処理を そのままVue.jsに置き換えていくという感じですね。 実際、Google Trendを見ても ここ数年でVue.jsの人気が急激に伸びているのは事実です。 （実はReactにも大差をつけている） 【Google Trend JS比較】 https://trends.google.com/trends/explore?date=today%205-y&q=vue.js,react.js,angular.js ここでは、実際に実装してみて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レガシーコード改善に役立つ5パターン〜インタフェースの抽出〜 – ORATTA Labs Blog