あたりまえのことをあたりまえにやる難しさYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
毎週のように依存パッケージを上げ続ける努力 - CARTA TECH BLOG
皆さんこんにちは。fluctにてfluct SSPという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 依存パッケージの更新、どうしてますか？ 今や数多くの言語でパッケージマネージャが提供されており、みなさんも日常的にコミュニティによるパッケージエコシステムを活用していることと思います。 ですが、この依存パッケージの更新については、どのようにしていますか？ セキュリティfixなどを除き、以下のようなことになっていることが多いのではないでしょうか？ チームの「いい人」が頑張って更新し続ける その人の謎の情熱が消えると更新されなくなってしまう たまに気がついたら頑張る 「いい人」が頑張るタイプの亜種 気が付かなかったら更新されない 更新はリスクなので塩漬けにする プロダクトは定期的に作り直す前提 CIでテストを回し続けているのに更新しないなんて……とモヤ
テスト書きすぎ問題を避ける - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 新しい職場で提案したら歓迎されたので投稿しておく。 テストコード開発方針 漫然とテストコードを書いていると、以下のような問題が発生することがある。 テストに時間がかかりすぎ、待ち時間が発生したり、テスト結果を見なくなったりする テストコードの開発とレビューに時間をかけたが、そのコストに見合う利益を得られない このような問題を避けるため、以下の方針を定める。 ビジネス上の価値に比例したテスト コードの価値をビジネスへの影響や回避方法の有無により以下のようにランク付けする。 メジャー サービスの主たる機能に影響する 再現条件が広い 回避方法
デプロイ自動化を進めるためのチェックリスト | Ryuzee.com
いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター
今日の習慣が明日をつくる～よりよい技術者を目指して～
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
組織にテストを書く文化を根付かせる戦略と戦術
事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
サーバーレスアーキテクチャという技術分野についての簡単な調査 - Qiita
BaaSの制約で実現しにくい要件があったときに、サーバーレスアーキテクチャという選択肢は魅力的に見えてくる。そこで今回は最も柔軟性が高いサーバーレスインフラストラクチャだと思われるAWS Lambdaを取り上げ、BaaSの代わりになりうるか検討する。 AWS LambdaのファンクションはJava 8で書ける。ということはGroovyでも書ける。ドメインクラスをJava/Groovyで書いてLambdaファンクションのなかで利用することができれば、サーバーレスアーキテクチャでも本格的なアプリケーションを開発できそうだ。 今後のアプリケーションインフラストラクチャ選択において、従来型のアプリケーションサーバーと、近年普及してきたBaaSに加え、サーバーレスインフラストラクチャという選択肢も増えるとすれば有意義だ。 非常駐型のデメリット 歴史的にはCGI/PHPのようなイベント駆動型のアプリケ
Hashicorpの新プロダクト「Otto」を試してみた
全国1000万人の大トロ好きのみなさんこんにちは。 Hashicorpから新たにOttoと呼ばれるプロダクトがリリースされました。 OttoはVagrantの後継となるもので、開発からデプロイまで一気通貫で行うことができるソリューションでマイクロサービスでの活用も考慮されて作られているということで早速試してみました。 軽く触った印象としては、Vagrant、Packer、Terraform、ConsulなどいままでHashicorpが提供してきたツールを組み合わせて一気通貫で操作できるようになった、と考えるとわかりやすそうです。 インストール https://ottoproject.io/downloads.html にアクセスして自分の環境にあったバイナリをダウンロードして展開します。展開したら実行できるようにPATHに追加します。 僕の場合はアーカイブを~/tools/otto/に配置
RSpec についての議論
セコン @hotchpotch 時々 rspec 書くと、そもそも文法なんだっけ、expectｪ… be_true じゃだめで be_truthyェ… このとき美しく書くには…みたいになってつらい… assert 最高みたいになる 2015-05-27 09:49:54
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「＠Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」（単一コードベースへの取り組み：なぜGoogleは単一リポジトリに数十億行ものコー
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
続: OSSプロダクトとコミュニティの話 - たごもりすメモ
先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
KAIZEN platform Inc. における運用自動化
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
初めての新規サービス開発を通して学んでいること - クックパッド開発者ブログ
こんにちは。投稿推進部の清水(@pachirel)です。 2009年にクックパッドに入社してから、インフラ周り、クックパッドの人事周り（採用・評価）や広告周りのシステム開発を担当していました。 2014年4月頃から、2〜3名の小さなチームで新規サービスのプロトタイピングをいくつか行っています。 企画の詳細は省きますが、私がこの10ヶ月ほどで学んだことをまとめました。アジャイル開発やLean startupの考えに共感しているので、そこから得た内容に私の体験を付け加えたものになっています。 今回はプログラミングに関する技術的な内容は含まれていません。 なぜ作るか スタートアップが失敗する原因で一番多いのは「人が必要としていないものを作ってしまった」というものです。 The Top 20 Reasons Startups Fail 社内の新規サービス開発でも同じ傾向があるのではないでしょうか。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HashiCorp
