全国の市区町村の名前とコードをデータベーステーブル化したもの、すなわち市区町村マスタはITシステムを作っていれば何かしらの場面で必要になるものです。 ではその市区町村マスタを作るための元データはどこから手に入れたらいいものか。 そして「作る」というのもありますが、市区町村は再編されるものですから最新の変更にどう追従するか、しかもそれを自動化できるかというのも大いに気になるところですね。 エムスリーエンジニアリンググループ三浦(@yuba@reax.work) [記事一覧 ]です。 Unit1（製薬プロモーション）およびUnit9（治験臨床研究支援）のエンジニアです。 今回は私も皆様とまったく同じように市区町村マスタのデータ源に悩んでいろいろ調べましたので、それで得た知見を共有させていただこうと思います。今回は代表的な3つのデータソースをご紹介し比較していきます。 ほしいのはこんな感じのデ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
最近は個人開発は自分のOSSのメンテで手がいっぱいになってしまったのでサービス開発のようなものは普段あまりやらないのだが、大学院*1で今学期、何作ってもよいという感じの授業を取ってWeb/iOS/Androidアプリ*2を全て作るという体験をする中で、たまたま個人開発のコストを抑える活動をしたので、その時に調べたり考えたりしたことを書いておく。 Herokuで無料にする Herokuでは毎月550時間free dynoが使え、クレジットカードを登録しておくと更に450時間、合計1000時間無料で使える。Herokuは30分アクセスがないと一旦停止するが、今回授業で作ったサービスでこれを使い切らないことは明らかだったので最初はこれでセットアップした。セットアップも簡単だし、PostgreSQLも無料でついてくる。 ただ、コールドスタートに10秒くらいかかり、これがこのサービスではUX的に致命
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は、bytefish氏による「Use Chrome DevTools Like a Senior Frontend Developer」（2020年7月21日公開）の和訳を、著者の許可を得て掲載しているものです。 #シニアフロントエンド開発者みたいにChromeデベロッパーツールを使おう 開発環境にChromeを選ぶなら知っておきたい12のテクニック Photo by Morning Brew on Unsplash さて、何らかの理由で、開発ブラウザとしてChromeを選んだとします。次は、デベロッパーツールを開き、コードのデバ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
なんてのは無いということが。 I Have Created 50 Games in 2014 (http://www.asahi-net.or.jp/~cs8k-cyu/blog/2014/12/12/games-in-2014/) 作ったものは上のページにまとめた。全ゲームのスクリーンショットがアニメGIFになっていて、クリックすればそのゲームが遊べる。個人的な意見としては、左上の方が楽しめて、右下のほうが退屈できます。 すべてブラウザで遊べる昔ながらのミニゲーム。半分Flash、半分HTML5。HaxeとCoffeeScriptで書いた。ソースも置いてあります。 1年で50作れば年の終わり頃には余裕で面白いゲームを狙って作れるようになるかなあと思ったけど、脳内で面白そうと思ったゲームが実際に作るとひどくつまらないということは相変わらず多発するので、やはりイケてるゲームを作る簡単なセオリ
クラウド技術の進化や開発ツールの充実などを背景に、Webエンジニアに求められる開発知識は日々更新され、右肩上がりに高度化していっている。常に成長し続けることなしに、エンジニアが理想的なキャリアを描くことはできないと言っていいだろう。 そんな状況下、柔軟に知識と経験を増やしながら伸びていくエンジニアと、そうでないエンジニアとでは何が違うのか。弊誌姉妹サイト『＠type』が主催する『エンジニア適職フェア』（東京ドームシティ）でこのほど、優秀なエンジニアを輩出することで名高いIT企業3社の開発トップを招き、「エンジニアが成長する職場の条件とは？」をテーマにトークセッションを開催した。 《登壇者》 ■クックパッド株式会社 執行役 最高技術責任者 舘野祐一氏 ■株式会社はてな 執行役員 サービス開発本部長 大西康裕氏 ■株式会社nanapi 取締役 執行役員 CTO 和田修一氏 エンジニア育成の取り
はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると
Forkwell のエンジニアの1人、正徳です。先日、入社した馬です。 最近Hubotでbotを作り始めて、朝会を通知させたり、Github Issueの件数を喋らせたり、と遊んでいます。 Hubotの記事はググればたくさん出てきて、喋らせるのはとても簡単です。ところが「Hubotでテストを書く方法」となると、情報がほとんど出てきません。 ChatOpsをやっているエンジニアが、まさかテストコードを全く書かずにbotを開発してる訳がないと思いますが、不思議と記事が見つかりません。 先人のブログなどが無かったので、自分で四苦八苦しつつ、なんとかTDDでHubot開発できる環境が作れたので、ブログにまとめてみました。 目次 Hubotでbotを作る方法 テスト用にモジュールを入れる mocha の実行方法 greet のテストを書く cron のテストを書く time モジュールを使っている
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
20141010 万葉帰社日発表 万葉積み重ね from tatsuo sakurai 内容 チーム積み重ねっていう前に公開したものと似てる、チーム開発とか社内での工夫とか、あいかわらず僕の好きそうな内容。 なんとなく万葉で中の人達がやってることを小出しにしたいなって思っていたんだけど、どこでやろうかなあ…みたいなのが思いつかなくて、社内で発表した。 万葉は僕にとって働きやすい環境で、なんでかっていうと、自分達で会社の制度や仕組みなどをリファクタリングしたり、機能追加したりしてるからかなあって思う。 もっと効率を良くする仕組みを、効率よく採用できる。（や、まあ、普通にどこでもそうしてますよね…^^;） その理由として、社長が現役プログラマーというのは大きいと思う。（実際社内でも一番書いてるくらい書いてる。っていうのを意外と知らない人がいるって話をちょいちょい聞くのでスライドにもいれてみた。
nanapiさんとはてなさんが共同で主催された、開発フローや開発手法、継続的インテグレーションや継続的デリバリーなどDeveloper Productivityに関する勉強会、「nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー」に参加してきました。 オープニング @wadapさんによる発表。 開催の経緯 福岡でnanapi勉強会vol3を開催 京都でもやってほしいとはてなの@stanakaさんから要望が せっかくなら東京でもやりたいです vol4開催 来週京都でも近い内容でやる（はてなさんのオフィスで） nanapi IGNITIONチームの開発フローとその構築 / nanapi @vexus2さんによる発表。 自己紹介 サーバサイドエンジニア PhpStorm Advent Calendarを24日分くらい書いた nanapiではnanapi
10月2日に「はてなとnanapi の開発フロー nanapi勉強会 vol4」に参加してきました。 そのときのメモです はてなとnanapi の開発フロー Twitter で話して決めました 福岡でvol3はやった 合同開催なので、来週は京都 IGNITION チーム @vexus2 our service nanapi 月間 2,500万UU answer あついサービス IGNITION http://ignition.co/ 新聞のコラムのようなサービス メディア 話すこと 開発フロー 開発フローの選定 PhpStorm のことは話さない チーム ディレクター：1人 編集：1人 エンジニア：2人 デザイナー：1人 開発の流れ 一般的な流れ スクラム 物理かんばん（ホワイトボード）を使っていた ふせんとissueの二重管理 振り返りのときに看板の移動が面倒 ログとして残すのが辛い 代
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
こんにちは、ライターの岡田大です。 お待たせしました。特別編「トップエンジニアたちの夜」のPart4をお届けします。 ※Part1～3未読の方＆内容を忘れてしまった方は、Part1・Part2・Part3を一読してからお楽しみください！ リモートワークを成功させるために必要なモノとコトについては前回お伝えした通り。ルールとマナーなくして成り立たないことは言うまでもなく、そのことをメンバー（とくに新人）に徹底させるために、リモートワークを積極的に導入している伊藤氏は、ガイドラインをドキュメント化することにより意識の共有を図っているという。その際に活用しているのが、技術情報共有サービスQiita:Teamである。堀木氏の口から「Qiita:Team」という言葉が発せられるやいなや、参加メンバー一同がこれに食いつき、座談会はチーム内における情報共有に関する話題で持ち切りになっていった……。なお、
この記事面白かったです！ 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた
BambooHR is all-in-one HR software made for small and medium businesses and the people who work in them—like you. Our software makes it easy to collect, maintain, and analyze your people data, improve the way you hire talent, onboard new employees, manage compensation, and develop your company culture. It’s designed to set you free to focus on what matters most—your people.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
