サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
keisukeohta.hatenablog.com
ある製品の開発プロジェクトがあって、そのプロジェクトに途中から入ることは少なくないと思います。そんな時に、めったにないとは思うんですけど、本来はあるはずのファイルがなくて「あれ?」ってなったことはありますか? ただそのファイルがそもそもなかったのか、過去に削除されたものなのかわからない。ただすべてのコミット履歴を確認するのはあまりにも骨が折れる作業です。 そこで今回は、少しでもコミット履歴を追う作業を効率的にやるコマンドを紹介したいと思います。そのコマンドがこちら。 git log --diff-filter=D --summary これのコマンドは、過去のコミット履歴の中でファイルの削除が含まれているコミットだけを抽出し、削除されたファイル名を表示してくれます。 その上で、vimの検索コマンドを使ってそのファイル名を入力すれば、一発であるべきファイルが過去のコミットの中で削除されたものな
技術は本当に流行り廃りが早いですよね。追いついたと思えばすぐに新しい技術が出てくる。技術者は常に最新の技術をウォッチして追いかけなくてはいけません。 とは言え、すべての最新技術を追いかけるというのは無謀というもので、そんなことしてたらいくら時間があっても足りないという話になります。情報収集は手段であり、それ自体が目的化してしまっては元も子もありません。 そこで1つ疑問が湧いてきます。「追うべき技術は何なの?」という疑問です。そこで今回は、エンジニアの僕が2016年に個人的に注目している技術を共有したいと思います。 React これは既にエンジニアとして経験がある人であれば知らない人はいないと思います。ご存知のとおり、facebookが開発したJavaScriptフレームワークですね。 facebook.github.io Reactは発表された時から話題を呼んで、いたるところで「React
はじめに Amazonがクラウドサービス「Amazon Web Services(以下、AWS)」を2006年7月に公開してから、もうすぐ10年が経過しようとしています。 今ではInstagram、Airbnb、Netflix、Vineといった有名なサービスから、趣味レベルで作ったサービスまで、国内・国外問わずありとあらゆるWEB・モバイルサービスのインフラとしてAWSが利用されるようになり、もはや開発者にとってなくてはならない開発インフラと言っても過言ではありません。 しかしその一方で、まだまだ発展途上のサービスということもあり、いざ利用しようとすると「もっとこうしたい」とか「こういう風にできればなー」といった不満や要望があるのも事実です。 AWSの代表的なDBサービス「Amazon RDS」で日本時間(JST)が使えるようになったのも、2015年12月とつい最近の話だったりします。 d
Ruby(on Rails)で作られたプロジェクトで開発をしているとたまに困ったことがおきます。それはブレークポイントを作れないことです。 公式ドキュメントにはできるっぽいことが書かれてはいるのですが、なんだかブレークポイントの定義が違うようで、デバッグのためのブレークポイントではなさそうです。 自社のプロダクトを開発している時に、どうしてもブレークポイントを貼って開発したいという状況が発生しました。そこでいろいろ調べたところ、ブレークポイントを貼れる「pry-byebug」というgemを見つけました。 使ってみたところ、けっこういい感じだったので今回は「pry-byebug」の導入から使い方までを共有したいと思います。 前提条件 最初に、「pry-byebug」を導入するにあたっての影響がありそうな前提条件を書いておきます。 Ruby 2.1.2 Rails 4.0.5 導入 Gemfi
見積もりは深いですね。深すぎる。深すぎて溺れかけます。 見積もりなんて言葉は、ピラミッドや古墳、パルテノン神殿が作られてた大昔から存在すると思うのですが、正確に見積もることがどれだけ難しいことか…。 だから最近、ソフトウェア界隈で「アジャイルvsウォーターフォール(vsDevops)」戦争が勃発したり、ベンダーとエンドユーザーの構築遅延をめぐる訴訟合戦が絶えなかったりします。 simplearchitect.hatenablog.com arclamp.hatenablog.com https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/blogs.msdn.microsoft.com www.infoq.com ledsun.hatenablog.com そんな時に今月のWEB+DBプレス vol.93で見積もりに関する記
最近、スタートアップ界隈を中心にエンジニア周りの職種が増えている気がします。 ちょっと前の例で言うとグロースハッカーに始まり、グロースエンジニア、リードエンジニア、プログラムマネージャー、プロダクトマネージャーなどといったところでしょうか。 そんな感じで様々な職種がエンジニア周りで増えつつありますが、先日も当ブログで取り上げたテック系podcastのrebuildで、ゲストのhigeponさんがテックリードという職種(役割?)について触れられました。そこで今回は、そのテックリードについてまとめてみたいと思います。 テックリードとは何か? テックリードはいわばチームやプロジェクトの班長で、いわば「ミニCTO」。 そのチームで技術的な決断に責任を持つ人。テクニカルにそのチームをリードする。コードレビューを一番やって、チームのコードの品質に責任を持つ人。 higeponさんは、一生エンジニアをや
PDCA。そう、PDCAです。ビジネスマンであれば知らない人はいないんじゃないかと思うぐらい有名な改善サイクルの1つですね。 ところで、そのPDCAってなんの略なんでしょうか? 一番一般的なのは、 P: Plan(計画) D: Do(実行) C: Check(検証) A: Action(行動) だと思うんですけど僕だけでしょうか。 で、この定義、ずっとしっくり来なかったんです。PDCはわかるのですが、Actionって「Doと何が違うの?」と。たしか就職活動をしている時ぐらいにPDCAっていう言葉を知って、今に至るまでずっとその疑問が胸につっかえていてもやもやしていました。 そんなある日、「ウェブDBプレス」っていうソフトウェア開発に関する雑誌を手に取ったんですよね。その中に、「視点を変えてみよう」というコラムがあって、今回は「学びのサイクルの最初の一歩は?」というテーマだったんですけど、そ
2016年6月24日追記 年始にこの記事を書いてから約半年、他にもいくつかのpodcastを聴き始めましたので追記しました。 はじめに iPhoneを持っている人でpodcastを聴いてる人って意外と、いや普通に少ないと思います。かくいう僕もpodcastなんて全然聴いてませんでした。 しかし、僕は1年ぐらい前からpodcastを聴き始めて、今では音楽よりもpodcastを再生していることの方が多いように感じます。そこで今回は、表題のとおりエンジニア・デザイナー向けに購読したほうがいいと思うpodcastをまとめてみたいと思います。 rebuild.fm webエンジニア界隈ではもはや知らない人はいないのではないでしょうか?シックス・アパートやクックパッドでエンジニアをしていた、もはやエンジニア界のアイドルになりつつある宮川達彦さんのpodcastです。 rebuild.fm 一休.com
このページを最初にブックマークしてみませんか?
『keisukeohta.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く