ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳
manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう？ ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう？ これは自戒をかなり含むが不満をSN
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性
Twitter、ついに初の黒字に
米Twitterは2月8日（現地時間）、2017年第4四半期（10～12月）の決算を発表した。2013年の株式公開以来、初めての黒字になった。 ジャック・ドーシーCEOは株主向け書簡で、28％のコスト削減が奏功したと語った。 売上高は前年同期比2％増の7億3200万ドル、初の純利益は9108万ドル（1株当たり12セント）。前年同期は1億6700万ドル（1株当たり23セント）の赤字だった。株式報酬費やTACコストなどの特別費用を除いた非GAAPベースでは1億4140万ドル（1株当たり19セント）の黒字だった。 売上高、非GAAPベースの純利益ともにアナリスト予想（6億8640万ドル、1株当たり14セント）を上回った。
「まずは当たり前のことをやってから言え」 | はったりエンジニアの備忘録
この投稿は社内の Qiita:Team に書いた記事を加筆・修正したものです。 「まずは当たり前のことをやってから言え」 この言葉は前職でお世話になった先輩の言葉です。障害が起きたときに最後の砦と信頼されていたエンジニアの方です。 いま思うとこの言葉が自分のエンジニア人生をより良くしてくれました。 「信頼されるエンジニア = 技術力が高いエンジニア」とは限らない 以前は「信頼されるエンジニア = 技術力が高いエンジニア」だと思っていましたが、実際にはそうとは限りません（技術力が高いエンジニアを批判する意図はありません）。 社内で周りを見渡せば納得すると思いますが、多くの人から信頼を得ているエンジニアはこんな人ではありませんか？ 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い
三菱UFJニコスのシステム障害の原因が判明、3個のHDDが同時に故障
マスターデータから中間加工ファイルを作成するバッチ処理のシステムでHDDが故障し、障害が発生した。三菱UFJニコスによれば、HDD15個で一連の機能を果たしており、そのうち3個が同時に故障した。「2個までの同時障害は自動復旧可能な仕組みを設けていたが、3個の故障は想定外だった」（広報）。同社はシステムやHDDの開発企業を明らかにしていないものの、「発生確率は極めて低いとの報告を受けている」という。 故障したHDDは、障害が発生した2017年12月26日中に交換したが、利用会員の売上データ処理などに遅れが発生した。一部の利用会員に2重請求が発生したほか、請求が遅れるなどの事態につながった。同社はシステム機器の監視体制を強化するなどして対策を講じるという。
特定のRakeタスク内でのみ使うメソッドの定義方法
Rails内で使うRakeタスクに以下のようなものを使おうとしました。 namespace :task1 do task :do_something => :environment do foo end def foo p "task1" end end namespace :task2 do task :do_something => :environment do foo end def foo p "task2" end end namespaceで区切られているためfooメソッドは別のものとして解釈されると思っていたのですがオーバーライドされてしまいました。 特定のRakeタスク内からしか呼び出さないメソッドのスコープを限定するにはどうすればよいのでしょうか？ 特に決まった方法がないのであればtask1_fooなどのような命名規則を適用させようと考えています。
【翻訳】"Factory Girl"が"Factory Bot"に変わった理由（と移行手順） - Qiita
2017年10月に、Rubyのライブラリ(gem)である"Factory Girl"が"Factory Bot"に変わりました。 名前が変わった理由が以下のページに記載されていたので、翻訳してみます。 プロジェクト名の歴史 Factory Girl このライブラリはもともと2008年に"Factory Girl"という名前でリリースされました。 この名前を選んだ理由は書籍「デザインパターン」に載っていたファクトリメソッドパターンとオブジェクトの母（Object Mother）パターンに従っていたことと、ローリング・ストーンズに同じ名前の曲があったためです。 Factory Bot "Factory Girl"という名前はこのライブラリの存在を知った一部の開発者を混乱させました。また、不快で問題があるように感じる人々もいました。そのため、2017年10月に私たちはこのライブラリの名前を"Fa
「どうぶつタワーバトル」というアプリを作った話とか自分のこととか
こんにちは。スマホアプリなど個人で作っているYabuzakiです。 「どうぶつタワーバトル」という昨年（2017年）僕が作ったスマホゲームアプリがあるのですが、それについて色々と書いていこうと思います。 「どうぶつタワーバトル」についての説明を簡単にすると、「どうぶつを積んでいって落とした方の負け」というルールのみの対戦ゲームアプリです。 もともと対戦要素のない「どうぶつタワー」という１人でどうぶつを積んでいくアプリを４年前にリリースしていて、それに対戦要素を加えたものです。 ゲームアプリを作るときはインストールして５秒で遊べるアプリを作ろうと思っていることもあってどちらも本当にシンプルなアプリです。 今でも信じられないのですがAppStore、GooglePlay共にランキング１位を獲得しました。 AppStore GooglePlay アプリをいろんな方に遊んでいただけるようになった昨
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rakeタスクの中だけで使うメソッドはRefinementsで定義するとべんり - Qiita