システム開発改善記。1年でがらりと変わったとある組織の開発環境をBefore・Afterで振り返ってみる - Tbpgr Blog
私はシステム開発会社に勤務しているソフトウェア開発者です。 親会社向けのWebシステムの開発や、親会社のお客様のシステムの受託開発が主なお仕事です。 CodeIQの出題者の仕事を個人として行っていて、そのきっかけで本業の一部として金曜日のみ別の会社の システム開発をお手伝いすることになりました。これが2015年6月末のお話。 その時のエントリがこちら。 tbpgr.hatenablog.com 週1の現地勤務以外にも個人の時間で、個人としてリモートでもお手伝いしています。 今回振り返る内容はこの金曜勤務の会社の話のみです。 経緯 このエントリをまとめるに至った理由が実はありまして、今年は本業の開発が佳境にさしかかり、週に1回私が不在になるのがけっこうな痛手になってしまいました。 そのため、2016年6月末をもって金曜日に別の会社をお手伝いするのは終了になりました。 個人としては継続してお手
Ruby + Web APIに関わる情報のリンク集 - Tbpgr Blog
Ruby + Web APIに関わる情報をまとめます。 Microservicesの需要が高まる昨今、Web APIの導入に対する需要も当然高まっていると思います。 導入企業の情報を見るとRubyを活用しているところが多いように感じます。 そこで、Ruby+Web APIに関わる情報を調べてみることにしました。 認証, 認可 Web APIの話では無いのだが、認証を切り出すケースは多いだろうということで。 qiita.com エラー処理 qiita.com API Document qiita.com Grape RESTful APIを簡単に作るためのDSLを備えたRubyのフレームワーク。 Grape - GitHub Grape関連情報 dev.classmethod.jp qiita.com qiita.com qiita.com スライド Ruby Web API Tools A
システム開発における自律した組織と過度に規律を重視する組織の比較 - Tbpgr Blog
概要 システム開発における自律した組織と過度に規律を重視する組織の比較をします 経緯 現在私が本業で所属しているチームや、週一で勤務している外部企業は、 各メンバーが自律して考え、行動する体制をとっています。 週一で勤務している企業に関するエントリーは以下をどうぞ。 cnxt.jp cnxt.jp この2つの企業と関わる前は、 分業・過度の規律重視・部分最適化ベースの組織に所属する機会が多かったです。 主にSI'erの下請け（多重構造）を想像していただければ問題無いです。 双方の組織を経験した上で、お互いの体制がどのような結果を生み出しているか整理してみます。 比較 項目 過度の規律重視 自律した組織 開発スピード 遅い 早い 技術選定の自由度 低い 高い 労働時間 非常に長い 短い 不合理があるか？ 非常に多くある あまりない ドキュメント 過度に多い 必要最低限 開発環境の快適さ 不快
Ruby on Rails | ActiveModel::ModelでDB以外のモデルを定義 - Tbpgr Blog
概要 ActiveModel::ModelでDB以外のモデルを定義 内容 ActiveModel::ModelでDB以外のモデルを定義します。 これにより、検索フォーム等についてValidation等の機能や、 form_forタグなどを利用出来ます。 サンプル signin_controller require "pp" class SigninController < ApplicationController skip_filter :authorize, :except=>:index skip_filter :authorize, :except=>:signin def index @signin_form ||= SigninForm.new(nil, nil) @message = flash[:message] end def signin @signin_form ||
システム開発の現場改善記 - Template Method パターンでチームの開発工数を 1 / 10 にした話 ※オチ付 - Tbpgr Blog
概要 Template Method パターンでチームの開発工数を 1 / 10 にした話です システム開発の現場改善記シリーズの目的 下記のリンク先を参照ください システム開発の現場改善記 - 目的 前提 10 年以上前の話 XP とか JUnit とかの話題が出はじめたばかりのころ 当時 SI'er の下請け会社に正社員として所属。様々な現場に派遣されていた 最高で 7 次派遣！ 自社の名刺？何それ飾り？ Java の開発の話。 当時 Java の経験は半年程度 目次 プロローグ - 入場 - コードリーディング 提案 サンプル実装 横展開向けの資料作成 実開発フェーズ 無事納品 効果測定 エピローグ - その後 - 1. プロローグ - 入場 - SI'er の下請けで働くプログラマだった私。 今回の現場は Java を用いたミドルウェア開発 です。 この案件は継続案件であり、すでに
システム開発の現場改善記 - esa.io 導入編 - Tbpgr Blog
概要 esa.io 導入の過程について 経緯 世の中のシステム改善の情報はよく見かけるが、 自分も改善しようとした時に、どのようにしたらいいか分からない 。 実際の改善をするまでの 細かな過程などを参考にしたい 、という相談を受けました。 同じような情報が欲しい、という方が他にも居るかもしれないので 私の業務の改善実績を公開することにします。 需要がありそうなら、シリーズ物として地道にアウトプットして行こうかと思います。 ポイントとして、私自身は優秀なハッカーや優れたマネージャーなどではなく、 ありふれた開発者の一人 に過ぎません。 私の性格については、引っ込み思案で内向的。 どちらかという消極的で、お世辞にもコミュニケーションが上手なほうではありません。 勉強会に行って、 懇親会でほとんど発言せずにしょんぼり して帰ったり、 RubyKaigi のオープンスペースの昼食が怖くて、 豪華な
妻子持ちの凡人プログラマが限られた時間で行う趣味の開発 - Tbpgr Blog
概要 妻子持ちの凡人プログラマが限られた時間で行う趣味の開発について ターゲット 仕事も大事だけど家庭も大事にしたい。でも趣味の開発もしたいソフトウェア開発者さん。 元々実力が高い方はすでに実践済の内容であると思われるため、あまり参考にならないと思います。 ライブラリの作成などに関して、不慣れで、試行錯誤している段階の方向けです。 この記事をまとめる動機 業務外の限られた時間で大小さまざまなソフトウェアを作りたい。 仕事も家庭もあるので、趣味の開発のためにまとまった時間が確保できるとは限らない。 そのため、特に大きめのソフトウェアを作る機会が少なくなりがち。 現状の問題点 大きなソフトウェアを作る際に、個別の機能を別々の小さなタスクにして、 地道に開発することもできますが、開発が長引いたり間が空いたりすると 成果物に対する熱が冷める 全体の設計思想が頭から離れる などの問題が発生してしまい
GoFのデザインパターンの自作サンプルまとめ（主にRubyで実装。一部Java） - Tbpgr Blog
概要 GoFのデザインパターンに関して取り扱った記事のまとめ 生成のパターン AbstractFactory | 詳細を意識せず抽象的にインスタンス生成を行う Builder | 複雑なインスタンス生成手順をクラス化する FactoryMethod | インスタンスの作成を独立させる Prototype | コピーしてインスタンスを作る Singleton | インスタンスが一つであることを保証する 構造のパターン Adapter | AとBのインターフェースのアダプターを作る Bridge | 機能の拡張と実装の拡張を分割する Composite | 容器と中身の同一視 Decorator | 飾りと中身の同一視 Facade | シンプルな窓口 Flyweight | 同じ物を共有して処理を軽量化する Proxy | 必要になってから作る Proxy | 必要になってから作る(Forw
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
