タグ

developmentに関するcastaneaiのブックマーク (38)

  • ダレずに開発を走り切る為の習慣

    重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ

    ダレずに開発を走り切る為の習慣
    castaneai
    castaneai 2015/12/24
    「億劫度」も見積もる、Github PR, issue のformat決める、こまめに成果を見せる、等
  • プログラマが知るべき97のこと

    プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中!すべてのプログラマにおすすめのがウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する(あなたはユーザではない)コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず

    プログラマが知るべき97のこと
  • 社名変更のお知らせ

    Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ

    社名変更のお知らせ
  • Slack: Be less busy

    ツールをつなげてスピードアップ生成 AI を活用して定型タスクを自動化し、お気に入りのアプリを Slack の中で使ってシンプルなワークフローを実現しましょう。 Slack プラットフォームについて詳しく知る 一人ひとりに最適な働き方をSlack を使えば、自分にとって最適な時間、場所、方法で、柔軟に仕事を進められます。会話や音声・動画クリップの送信のほか、ハドルミーティングを使用してリアルタイムでの話し合いも簡単にできます。 柔軟なコミュニケーション方法について詳しく知る チームのすべてが 1 か所にSlack の心臓とも言えるチャンネルは、必要な人や情報をすべて集めて整理できる場所です。チャンネルを使うと、部門、拠点、時差を越えて仕事を進められるだけでなく、他社との連携もスムーズです。 チャンネルについて詳しく知る

    Slack: Be less busy
  • ビルドプロセスの自動化で効率アップ

    Grunt.jsの紹介スライドです。package.jsonの扱いや、grunt自身の0.4.0対応が弱い部分が残りますが、数ヶ月前というところでご容赦くだされば、おおまかな概要を示しています。

    ビルドプロセスの自動化で効率アップ
  • ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!

    「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか? もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない!という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を2つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ

    ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
  • テスト駆動開発を継続する

    2013年はじめのTDD Boot Camp in 大阪 外伝 の資料です。 http://kokucheese.com/event/index/64957/

    テスト駆動開発を継続する
  • とりあえず30分でひととおり分かった気にはなれるアジャイル入門

    2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-menRead less

    とりあえず30分でひととおり分かった気にはなれるアジャイル入門
  • 事前設計とTDD - 2012-12-16 - やっとむでぽん

    実はモデリングが大好きです。元々はオブジェクト指向プログラミングを勉強しているところからUMLに(自然に)興味が向き、そこからオブジェクト指向設計とかオブジェクト指向分析とかそういう脇道にそれ(脇道とか言ったら怒られる!)、仕様も設計もこれからはオブジェクト指向だ!というありがちな若気の至りもありました。デザインパターンにも転んだし、責務!ロール!コラボレーション!ってのもやったし、重厚長大なフレームワークとかもなかなか楽しいですよねえ。ねえ? 今でも概念モデルとか大好物で、上の話を聞きながらうっかりとこんなオブジェクトモデリングをしてしまったりします。 そんなわけで、プログラミングする対象の仕様を理解しながら頭の中でモデリングして設計を進めてしまうのはやむを得ません。多かれ少なかれ、なにかしらの設計が浮かんできてしまいます。 でもTDDはテストを書きながら設計をします。先行して設計してし

    事前設計とTDD - 2012-12-16 - やっとむでぽん
  • なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423

    AIを使ったオートモーティブ領域のサービスとして、タクシー営業を最適化するお客様探索ナビを開発しています。 データサイエンティスト、ドメインアルゴリズムエンジニアが開発した結果を、MLOps、サーバサイドエンジニアがデータパイプラインとサーバAPIとして構築し、最終的にタクシー乗務員向けの最適走行ナビアプリとして提供しています。 このアーキテクチャの信頼性に対する取り組みとして、データパイプライン中でタクシー運行シミュレーションによる評価行ったり、API末端で案内経路に異常が発生していないか、交通規制を守って走行できるかのチェックなど、複数の施策を行っています。 スコープをアーキテクチャの信頼性にしぼり、データパイプラインとアーキテクチャの全体像をお話した後、信頼性を担保するために、行っている施策とそれを取り組むに至った考え方を紹介します。

    なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
  • ふつうの受託開発チームのつくりかた

    For the session A-4 ,DevLOVE Kansai 2012 Drive.Read less

    ふつうの受託開発チームのつくりかた
  • 設計と実装の狭間で - 急がば回れ、選ぶなら近道

    ・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて(懐古趣味の老人を除いた)皆さんが毛嫌いするCOBOL+汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず

    設計と実装の狭間で - 急がば回れ、選ぶなら近道
  • 「ニフティrクラウドユーザーブログ」は、移転しました。

    「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 > ニフティクラウドユーザーブログ

  • 「ニフティrクラウドユーザーブログ」は、移転しました。

    「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 > ニフティクラウドユーザーブログ

  • かっこ悪くて面倒でもテストコードを書こう - 今川館

    Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない

  • MVVMパターンの適応 – 2011年のMVVMパターンの常識 - the sea of fertility

    MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません><) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF

  • プログラミングは「名前」が9割。 - このブログは証明できない。

    プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは?」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や

    プログラミングは「名前」が9割。 - このブログは証明できない。
  • http://www.curiocube.com/mikata/index.php

  • Webアプリケーションエンジニアはノマドであれ(特定のサーバに依存しない方法) - blog.nomadscafe.jp

    弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元/管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技

  • PHPでTDD&CIワークショップ、Jenkins + PHP の各種プラグインパート資料 - Yamashiro0217の日記

    はじめに この資料は「PHPでTDD&CIワークショップ」 http://atnd.org/events/16626 で @yamashiro が発表するための資料だよ。 ワークショップ参加者じゃなくても記事読むだけで完結するようには書いてあるよ。 概要としては、Jenkins を使って PHP のウンコレガシーなコードをいかに綺麗にして行くかということを説明する。 自画自賛だけど PHPMD とか PHPCPD の使い方の説明の資料としてもそこそこイケてる資料になってると思いました。まる。 この記事に書かれてることは、割とTemplate for Jenkins Jobs for PHP Projectsとかぶってるけど、プラグインを絞ってあるのと、一個一個のプラグインについて解説、また実際にエラーが起きたときにどうすればいいのか書くよ。 Java と Jenkins のインストールとJ

    PHPでTDD&CIワークショップ、Jenkins + PHP の各種プラグインパート資料 - Yamashiro0217の日記