何のためにバージョンロックをするか | おそらくはそれさえも平凡な日々
外部ライブラリに依存する時に、どのようにバージョンロックをすべきかどうかという話。僕個人のスタンスです。 開発しているのがライブラリであれば依存ライブラリをバージョンロックをするべきではない 最低バージョンの指定に留めるべき(これは寧ろ積極的にやって良い) 依存ツリーが大変なことになってコンフリクトが避けられないため 実運用しているサービスやアプリケーション的なソフトウェアであればバージョンロックした方がいい これは「ある時点のビルドやリリースの再現性」のためが一番大きいと思っている 古いバージョンにとどまって良いというわけではない 基本的には、開発しているものがライブラリであれアプリケーションであれ、 とにかく依存先の最新についていく のが前提で、その前提に立った場合に、上のような考え方になるかな、と思っている。 特にライブラリ作者は依存ライブラリに非互換変更が入って動かなくなったら、頑
サービス成功のためにチーム開発でエンジニアができること - オールアバウトTech Blog
こんにちは、オールアバウトの筋トレエンジニア芸人の@musclemikiyaです。 普段はCafeSnapというiOS/Andorid向けのネイティブアプリの開発を行っています。 このアプリは大手チェーン以外の個性光るオシャレカフェの情報が満載なアプリですので、ぜひ使ってみてください。 さて、今回はサービスの成功可能性を高めるために、エンジニアがどのようにサービス開発に関わっていくかです。 エンジニアのサービスへの関わり方は様々だと思いますが、今回はよりサービス運営に近い立場のエンジニア（チーム）を想定しています。 ※チームの規模やフェーズによって当てはまらないこともあるので、一意見として参考にしていただければと思います。 コードを書く時間の最大化 ≠ サービスの成功 サービス開発をする上でエンジニアの重要な役割は、コードを書いて機能を実装することだと思います。 そう考えると、コードを書く
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Jenkins 2を使った究極のpipeline ~ 明日もう一度来てください、本物のpipelineをお見せしますよ ~
This document contains code for a Jenkins pipeline that defines stages for compiling, testing, packaging, deploying, and smoke testing a build. It also contains code to send notifications to Typetalk if the build fails. Additional code shows how to fetch pull request branches from a Git remote and check if a pull request is open for a given branch.Read less
基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
そろそろ PowerShell の一次配列の罠と回避について一言いっておくか - tech.guitarrapc.cóm
タイトルは一度いってみたかっただけです、生意気言ってごめんなさい。 他の言語同様、PowerShell にも一次配列があります。こんなやつ。 gist.github.com PowerShell は、型を持っているので Object[] 以外にも T[] (型の配列) などもあるのですが、他言語から見ると配列の扱いに癖があるように思います。まとまった記事にしたことなかったので、癖(挙動を知らなければ罠に思える)についてまとめます。 目次 目次 TL;DR 何がこまるの 罠となるポイント 暗黙の型変換 暗黙の型変換のルール シンプルな型変換例 暗黙の型変換の失敗例 一次配列の型変換 回避策 簡略化された配列宣言 よくある簡略な方法 明示的な宣言 単数を一次配列にする 要素の連結がオペレータによっては遅い 回避策 標準出力での配列型の要素が単体な場合の自動的な型変換 回避策 オペレータの配列と
アメリカの大学で受けたソフトウェア工学の授業が実践的ですごかった話 - stefafafan の fa は3つです
私はアメリカの大学で「インタラクティブメディアとゲーム開発」を専攻しましたが、その時受けたSoftware Engineeringという授業が色んな意味で素晴らしかったのでその授業がどう素晴らしかったのかを紹介していきます。 リアリティーがすごい まずこの授業、生徒数が80人ほどいます。ここから教授がみんなを約15人ずつの5つの会社に分けていきます。そうです、我々生徒は実は会社員なのです。 そして初日に出された課題は「自分たちの会社のミッションステートメントを考えてくること」です。 それだけでなく、プロジェクトマネージャー・プロセスエンジニア・リリースエンジニア・ドキュメンテーションマネージャー・クオリティーマネージャーの役割を会社のどの社員が取るのかを決めてこないといけないというのです。私たちは言われるがままにミッションステートメントを用意し、次の授業に備えました。 プロセスがすごい S
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
