ちゃちゃっとWebサーバーを立てる方法 - 何か着ていればいいよ
自分のやってきた方法の履歴を公開してみます。 やりたいこと 開発環境（Windows）であるところの自分のPCでちゃちゃっとWebサーバーたてて、静的コンテンツ確認したいな。 的な場合の話です。 題名とちょっとずれているような気もするけど気にしない。 例えば、htmlとcssとJavaScriptだけ用意して簡単な見栄えや動きを確認する場合なんかです。 動的なサーバーサイドの確認はまた違ったやり方することが多いです。 IIS WindowsならIISっしょ常識的に考えて！ そんなふうに考えていた時期が僕にもありました。 メリット Windowsと親和性が高い。 UIでポチポチやってWebサーバーが動かせる デメリット 最初に使うときはIISインストール必要。（特に昔はインストールディスクが必要でうざかった。） ぶっちゃけ、UIで設定とかメンドイ apache http server Web
Testing Casual Talks #2 に行ってきました #testingcasual - 何か着ていればいいよ
atnd.org 最初にまとめ なぜ、参加したのか 今年に入ってからテスト周りの学習をしているが勉強会には参加できていなかったので 本の読書会だと個人的事情で全部は参加しづらいが、一発ものだと参加しやすい テスト周りでの求職あったらいいな。 結果としてどうだった？ 内容には満足。*1 久しぶりに勉強会の懇親会に参加したがボッチで参加したので人と話すのが難しかった。 でも、少し話せて面識ない人と話すリハビリになったし、刺激を受けられた。 自分もその一端を担っていたSI業界との意識の差に分かっていたことだけどズシリと来るものがあった。 以下はほぼ自分用メモのまんまです。 ヒカリエがオシャレすぎてビビりながら入場 早くヒカリエに着きすぎた！ 辺りがオシャレ過ぎて居心地悪いを通り越して怖い…。 #testingcasual— wataru kubota (@wkubota) 2015, 5月 25
プログラミング上の勘所についての小ネタ - 何か着ていればいいよ
最近、プログラミング関連で思った事なんか雑多なものを適当に書き残す。 条件分岐の考え方 条件分岐を意味する部分をifやswitchではなく例外やgotoで実現してしまうというアンチパターン 自分にも経験があるが、やっているときは便利やんこれと思っていても… 後々、本質的な意味がボケてしまい可読性が下がってしまうんだよな。 自分はEffective Javaに出会わなければ今でもそこら辺、ちゃんと整理できてなかったかもしれない。 ショートサーキット ifなどのAndやOr条件についてのショートサーキットではなくネストをやたら深くしてしまう これも仕組みの理解が甘い時にやってしまった経験が。 ショートサーキットを利用するかネストを深くするかどちらが良いかはコンテキストにもよるけど… あと、Javaなんかの感覚でVB使うとショートサーキットがデフォルトではないのでやられてしまうんだよな。たしか。
アジャイルチームでコードレビューを実施する上での障害と対策 - 何か着ていればいいよ
このエントリは アジャイルCasual Advent Calendar 2014 の 3 日目のエントリです。 前日はa_suenamiさんのPDCAに関するお話でした。 "アジャイルチームでコードレビューを実施する上での障害と対策" ということで、現場で自分が今まで試行錯誤をさらしてみようと思います。 プロジェクト中にコードレビューを行って、実際に困った事とそれに対して試行錯誤しながら行ってきた対策をあげていきます。 どのようなレビューを行っているのか いきなりレビューがうまくいかない話をする前に、どんなコードレビューをしているのさ？って話を少々。 チケット駆動で開発する タスクはコーディングチケットとレビューチケットの二つがセット *1 レビューはコードを書いた本人以外が行う 他にも細かく書くと色々あるけれど、ざっくりいうとこんな感じになります。 障害その1 『レビューの工数が取れない
プログラマーとして夢想する作り捨てを許さない組織文化 - 何か着ていればいいよ
自分がソフトウェア開発プロジェクトにプログラマーであったり、プロジェクトリーダーであったり色々な役割を担いながら参加してきて、常に悩まされてきた問題についてちょっと考察してみようと思います。 それは作り捨てと個人的には呼んでいる、小規模な案件に比較的多く見られる事象です。 作り捨てとは何か？ 作ったシステム、PJ等を技術的負債を残して放置すること と、とりあえず定義します。 作り捨てられてしまったシステム…。そこでよく見るアンチパターンを列挙してみます。 ユニットテストなし 仕様書なし 機能仕様書 試験仕様書 その結果どのように動くのが正しいのか分からない その場しのぎの実装 staticおじさんの猛威 神オブジェクト コピペの嵐 などなどの実装のヤバさ 動作環境がない バージョン管理されてない 既存機能にテストがないと正直泣ける。 ユニットテストを作る工数を見積に入れざるを得ないけど、高
本当に議事録をExcelで作る必要ある？ - 何か着ていればいいよ
いや、無い。（反語） 経緯 下記の理由でExcelやWordで議事録を取るのが嫌。 いちいちMS Office起動するの面倒で、開きづらい Excelの場合はフォーマットが微妙 グループウェア（サイボウズ）や、BTS（Trac, Redmine）なんかにUpしづらい そこで最近流行のMarkDownで書いてやろうと色々試行錯誤した結果を残しておきます。 Markdownで議事録を代替する際の大まかな書式というか指針 そもそも議事録に必要な情報とはなんぞや？とか考えながら以下の情報を、 以下に記載したような感じで書いています。*1 MarkDownの記載方法は太字の部分。 会議体の名前 h1(#)にする 基本情報 日時 場所 主席者 上記をTableもしくはh2(##)で日時等のセクションつくって列挙 アジェンダ毎に記載する情報 アジェンダの内容 発言内容とその発言者 決定事項 リスク、留意
自分がいつもやっているソース解析の方法 - 何か着ていればいいよ
この記事作成時点の自分のソース解析のために普段行っている手法を記録しておきます。 前提 ソース解析の目的は主に以下のもの 不具合原因調査 ソースレビュー 仕様変更(追加)に伴う変更箇所調査 解析手法をどう選択するか 主に目的によって以下のように分けられますが、さほど厳密ではなくだいたいフィーリングでやっています。 仕様調査、変更箇所調査の場合。 ソースがオブジェクト指向に則ったクラス設計が概ねできているという前提で トップダウン*1で追っていきます。 具体的にはUMLのシーケンス図（とそれに伴うクラス図）を書き込みながら解析します。 レビューや不具合でエラーログから対象箇所が詳細に分かっている場合 ボトムアップでクラス図や仕様をメモしながら解析します。 上記のやり方で対処できない場合 今までソースの解析はだいたいUMLのクラス図とシーケンス図書けば分かると思っていました。 でも、クラスの責
Webアプリケーションの常識集 - 何か着ていればいいよ
タイトルは調子こいて大きな話になっていますが、自分がWebアプリを開発する上で常識だと思っている事。 常識集といいつつ、アンチパターンを集めている気もするなぁ。 コンテキストが書いてないんでアレなんですが、とりあえず列挙しておきたかった。 実装技術 実装技術のあれやこれや static変数は悪 staticおじさんの恐怖。 static変数に状態を保持して複数リクエストによって書き換えられたりしたら目も当てられない。 セッション変数は使いドコロを考えて セッション変数がゴッドオブジェクトになっちゃっていたりそういうの見た事あるんですよ。 メソッド呼び出しはが引数なし、戻り値なしで全部セッション変数経由とか…。 そこまで極端じゃなくてもセッション変数は気をつけて使うべきという話。*1 常にスレッドセーフを心がける JavaのSimpleDateFormatクラスのインスタンスを無邪気にシング
xUnitによるUnit Test作成の心理的障壁を突破する方法 - 何か着ていればいいよ
まず自分のチームでは機能開発のチケットにいちいち明記しないでもソースに対するxUnitでのカバレッジ*1を出来るだけ100%にしておく事になっており、レビューでは当然テストもレビューする形になっています。 そういったUnit Testが当たり前の状態に4-5年前からなっていて、それ以前の苦労をだいぶ忘れてきていたのですが、別のチームのプロジェクト振り返りに参加する機会があり、そのKPTなんかでxUnitのテストケースを作成するがProbremとしてあがってたりして別チームではUnit Testがなかなか出来ていないという事に気づいたのがこの記事のきっかけです。 Unit Testを作成するのに心理的な障壁がある Unit Testを書けないと言っているそのプロジェクトメンバー何人かにヒアリングした結果 以下のような理由からUnit Testが作成出来ていないということでした。 Unit T
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
