はじめに こんにちは植木和樹＠上越妙高オフィスです。10月14日（土）に地元上越市のIT関係者が集まっての勉強会が開催されました。 上越 Tech meetup #1 - connpass 当日はエンジニアだけでなく、上越教育大学や上越情報ビジネス専門学校の先生など、ITに関係する非エンジニアの方の参加や発表もあり、なかなかに幅広い内容が聞けました。 当日の感想を一言でいうと「楽しかった！」。二言でいうと「とても、楽しかった！」です。 私の発表内容 内容は先日行った Developers.IO 2017 の続きとなりますので、先にそちらを読んでいただけるとより楽しめるかと思います。 Developers.IO 2017セッション「A1. クラメソの請求を支える技術 〜40歳中年エンジニアの生存戦略〜」#cmdevio2017 他の方の発表＋感想など SPA実装最前線（POPCORN 五十川

ウィスキー、シガー、パイプをこよなく愛する大栗です。 2017年10月2日からAmazon EC2とAmazon EBSの料金が秒単位の請求となります。内容についてまとめてみました。 New – Per-Second Billing for EC2 Instances and EBS Volumes 秒単位の請求 今までEC2は従量課金モデルに従い、1時間単位の請求が発生していました。10月2日から以下のサービスについて1秒単位で請求が発生します。 Amazon EC2 Amazon EBS Amazon EMR AWS Batch 以下のように請求書は時間単位のままで小数で表示されます。 Source: <https://aws.amazon.com/blogs/aws/new-per-second-billing-for-ec2-instances-and-ebs-volumes/>

アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか？　上手くいく／上手くいかない取り組みの違いはどこなのか？　そもそもそれは本当にやるべきか？　組織とエンジニアの関係、評価はどのようにすれば良いのか？　といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく

よく訓練されたアップル信者、都元です。ゴールデンウィークは、越後湯沢の関東IT健保の宿泊施設トスラブ湯沢に行ってました。明らかに広すぎる部屋で、チェックイン以来出入りしなかった部屋が1つありました…っていう。まぁとにかくリフレッシュできました！ さて、私がJavaを触りはじめて10年以上が経ち、近年はJavaの入門書に触れる機会はめっきりありませんでした。が、最近しがないOLがJavaエンジニアを目指して頑張るということで、いくつか本を勧めたりしていたところに、「Java本格入門」が発売となりました。しがないOLには、少し古めのJava解説書を勧めていたこともあり、その最新知識へのアップデートとして、率直に良書が空から降ってきた感があります。 ちなみに本書は監修を行った会社名より「アクロ本」と呼んで親しまれています。購入はこちらからどうぞ。 個人的によかったなと思う部分 Javadocに触

渡辺です。 自分は「教える」ことにやり甲斐を感じます。 大学時代を思い返すと、家庭教師やサポートセンターのバイトをやってました。 ボードゲームをする時は、ルール説明などを行っていました。 ゲームのインストの一環としてインストカードやサマリを作ることもあり、プレゼン資料作りも得意になりました。 IT業界に入ってからは、勉強会の講師や資料作成・ハンズオンのチューターなどを行うようになりました。 技術書の執筆やIT系専門学校講師も経験しています。 最近では趣味のスノーボードで、インストラクターの資格をとり、スノーボードスクールで教えています。 「教える」ことが好きなんでしょう。 これまで、様々な分野で技術を教えてきました。 畑はまったく違ったとしても、解りやすく「教える」ための技術は大きく変わりません。 今回はそんな「教える」技術をまとめてみました。 なお、本エントリーの対象は、その分野に初めて

渡辺です。 以前、JUnit実践入門を執筆した経験もあり、社内でもブログの文章が読みやすいと評価を受けています（内容はともかくｗ）。 折角なので、技術ブログを書くときに注意する点をまとめてみました。 はじめに結論を書く 一番大切なこと、それは結論を最初に書くことです。 エンジニアには時間ありません。 はじめに、何が言いたいか、何を解決するのか、そこを最初に書かないと、読んでて苦痛です。 回りくどかったり、話がブレブレだと最悪です。 「XXの時、解決するにはXXする」とか「XXについて一言でまとめるとXXです」など、最初にまとめを書きましょう。 見出しですべてを伝える意識を持つ 見出しは大切です。 見出しを追っていけば、内容が頭に入ってくるのがベストです。 「見出しをまとめてしまったら、本文に書くことなくなった(´・ω・`)」となれば完璧です。 まさに今、蛇足しか書いてません（笑）。 短い文

gitで日本語ファイルが文字化けする こんばんは。小室です。gitを使っていて日本語のファイル名を入れるとファイル名の表示が崩壊するという経験をしました。 割と今までは放置していたのですが、きちんと日本語ファイル名を表示するコマンドを教えてもらったため、備忘録として記録しておきます。 若干人を小馬鹿にしたようなファイル名のファイルを配置したディレクトリをサンプルとして用意しました。 $ ls -la total 8 drwxr-xr-x 4 komurohiraku staff 136 Mar 25 19:09 . drwxr-xr-x 22 komurohiraku staff 748 Mar 25 19:08 .. drwxr-xr-x 10 komurohiraku staff 340 Mar 25 19:08 .git -rw-r--r-- 1 komurohiraku staff

はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1

こんにちは、クラスメソッドの稲毛です。 複数バージョンの Ruby を切り替えるだけでなく、ローカルディレクトリ毎に Ruby のバージョンを指定できる「 rbenv 」がとても便利だったので、インストール方法などを記しておきます。 ビルド環境の構築 Ruby をビルドする環境が構築されていない場合は、下記 ruby-build の Wiki を参考にビルド環境を構築する。 Suggested build environment rbenv + ruby-build のインストール rbenv で Ruby のインストールを行うので rbenv のプラグイン「 ruby-build 」を併せてインストールする。 Linux の場合 ここでは既に Git がインストールされているものとします。 $ git clone https://github.com/sstephenson/rbenv.

1 はじめに 2015/05/07(土)、JXUGC #13 東京 緊急開催 Xamarin のすべて！〜 無償化が発表されて大きな盛り上がりを見せる Xamarin を学ぼう〜に参加させて頂きました。 公開当初から、驚異的な参加者登録で、140人枠のとこり、一時300人をゆうに超えていたと思います。 遂にXamarinが無料で利用可能になったことと、新しくエバンジェリストとしてMicrosoftに入社されたちょまどさんが、登壇されるからだと確信できます。 （これを「ちょまど砲」と呼ぶのだとか・・・） 立ち見の方も多数です。 2 概要(1) ３種類のアプローチXamarinでアプリを作成する場合、大きく次の３種類のアプローチがあります。 Xamarin.iOS Xamarin.Android Xamarin.Forms 今回は、このうちのXamarin.Formsについて、主に画面設計のア

今日はCSV/TSVなどのテキストファイルをSQLで操作できるツール「q」の紹介です。 使いどころ データ処理を実施する時にはDBに保存されているデータやテキストファイルなどをCSVやTSV等の一定のフォーマットに変換して処理することが多いと思います。そのデータ内容を確認するときには、例えばExcel等に貼り付けることもあると思います。ただ、Excelではデータ量が数百万件規模になってくるとソフトウェアの制約上、処理が行えません。 データベースに保存されている大量のデータを処理・取得する際によく用いられるのはSQLです。SQLはデータ操作のための非常によくできたインターフェースであり、かなりの数のエンジニアが利用できるのではないでしょうか。 単純なCSVファイルに対してもSQLを利用して検索が実施できれば楽だと思って探していたところ、「q」にたどり着きました。 インストール qには様々なイ

はじめに こんにちは植木和樹＠上越妙高オフィスです。10/17（土）に新潟県は長岡市でJAWS-UG-NGの第2回勉強会が開催されました。 第44回勉強会 JAWS-UG-NG - 長岡IT開発者勉強会 (NDS) | Doorkeeper JAWS-UG-NGのNGはNiiGata/NaGaokaのNGで、新潟県のJAWS-UGです。第1回勉強会は2013年1月（NDS#30）に開催されており、当時AWS初心者だった私はJAWS Days 2013で総会が開かれると聞きご挨拶をしようと思っていたのにJAWS-UG-NGは参加しておらず、話の流れでJAWS-UG北陸のコアメンバーに誘われ人生初のLTを経験し、その後もJAWS-UG-NGの活動は行われていなくて謎のユーザーグループとなっていたので、じゃあ自分でJAWS-UG上越妙高を立ち上げようというきっかけになったという経緯があります。

はじめに こんにちは、6月からAndroidの開発を担当している荒川です。 この記事は以下の方を対象にしています。 リモートリポジトリにGitHubを使っている タスクや課題の管理を小〜中規模のプロジェクトで行っている 複数の開発タスクが並行して進むプロジェクトにアサインされている 開発者のみのタスク管理を主体的に行いたい タスク管理ツールを使っているがイマイチうまくいっていない この記事では、私が実践して良かった経験則を紹介します。誰でも真似すれば必ずうまく行くという保証はありません。この記事の読者の方が、担当しているプロジェクトに合わせてアレンジを加えるとより効果が増すかと思います。 開発者のタスク管理 モバイルアプリサービス部では、コミュニケーションツールにBacklogやTrello、Pivotal Trackerを用いている事を突撃！隣の開発環境 パート3【クラスメソッド編】の記

渡辺です。 先日、「JUnitのオブジェクト等価比較を怠けたい!」というスライドが公開されました。「オブジェクトのカスタムアサーションをどのように実現するか」という問題は、ユニットテストを実践していくとよく発生します。この問題に関して、先日のJJUG CCCでも相談されました。また、簡単に書ける仕組みは共有した方が良いのですよね。そんなわけで、cmtestというライブラリにまとめましたので紹介したいと思います。 Objectクラスのequalsメソッド Javaではオブジェクト同士の比較にはObjectクラスのequalsメソッドを利用することが定石です。これはユニットテストのアサーションでも同様です。テストした結果に作られる実測値と、テストの期待値を比較する時、通常はequalsメソッドを利用します。equalsメソッドを使った比較を行うのであれば、定番のassertThat構文を利用で

先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失

ドキュメントベースの単体テスト ソフトウェア開発では、テストケースをExcel等で管理し、テストをテストフェイズで実施する方式（以下、ドキュメントベースの単体テスト）が行われてきました。 ドキュメントベースの単体テストでは、テストフェーズが明確に切られています。テストフェーズでは、テスト担当者がテストを実施し、結果をドキュメントに記録します。必要に応じてエビデンスも残すでしょう。もし、テストが失敗したならば、不具合管理票（バグ票）を起票します。そして、不具合の原因を分析し、仕様書やソースコードを修正します。不具合が修正されたならば、もう一度テストを実行し、不具合がなくなるまでこのサイクルを繰り返し、品質を高めていきます。 このようなドキュメントベースの単体テストは、機能や画面を対象としています。そして、ほとんどの場合は品質保証を目的としています。テスト件数や不具合件数、不具合の発生原因や修

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

先日、”KILLER UX DESIGN”から「UXの心得14か条」を紹介しました。今回はChapter 2"Understand the Business Problem"より、ビジネスを理解するための45の質問を紹介します。 「デザインの話なのに、ビジネスを理解するための質問？」と思われるかもしれません。しかし、JJギャレットのUXデザインの5階層にはビジネス戦略がUXデザインの根底にあり、KILLER UX DESIGN にもビジネスモデルキャンバスを描くことを推奨してます。 ビジネスモデルキャンバスはただ描くことは簡単ですが、イケてるキャンバスを描くのはそれなりに難しく、ビジネスに関する知識や経験も必要になります。今回の質問リストは、開発者やデザイナが不足しがちなそういったところを補うものです。プロジェクトの立ち上げ時にこれらを意識し、不明な点があれば確認しておくことをオススメしま