ラズパイ絡みハード開発依頼の注意点（外注先に伝えて欲しいこと） - Qiita
はじめに メカトラックスの永里です。弊社は主にBtoB（ビジネスユーザ）向けハードウエアの受託開発と製造をやっていますが、特にラズベリーパイ（ラズパイ）をベースとした開発依頼ですと、ソフトは分かるけどハードはよく分からないというお客様が多いです。そういったご相談で良く漏れている点を受託者視点でまとめてみました。 ※以下ハードウエア慣れてる人には常識的な内容ですのでスルーしていただければ幸いです 何のために何をさせたいのか（目的と機能） 稼働環境（何処で動くのか） 電源 サイズ（寸法） 接続する機器・センサ（含 カメラ）等 通信手段と通信先 至極当たり前の内容ですが、依頼する側は求めてるものがクリアなので、こういった基本的なことを伝え忘れてらっしゃるのかと思います。 これら情報を検討してから相談するだけで依頼先とのやりとりが数ステップ省略でき、より本質的な課題（開発の本来の目的）に焦点を絞れ
抽象化によるブランチ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/BranchByAbstraction.html 「抽象化によるブランチ」というテクニック1は、ソフトウェアシステムへの大規模な変更を徐々に進めていくときに使われるものだ。 これを使えば、変更がまだ完了していなくても、定期的にシステムをリリースできるようになる。 こんな状況を考えてみよう。システムのかなりの部分が依存しているモジュール（あるいはライブラリやフレームワーク）があって、それをリプレイスしようとしている。 ※Flawed Supplier…欠陥のあるモジュール 抽象化レイヤーを作って、クライアントのコードとモジュールとのやりとりをそこに閉じ込める。 クライアントのコードの中でモジュールを呼び出しているところをすべて書き換えて、この抽象化レイヤーを経由させる。 各クライアントについて、この抽象化レイヤーを使うよう徐々に書き
「正しいものを正しくつくる」は、エンジニアの傲慢が詰まった書籍か - ビープラウド社長のブログ
「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」の著者、市谷聡啓さんが2019年6月に出版した「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を拝読しました。 本書をおすすめしたい人 プロダクト開発において、アジャイル開発での進めかたを知りたい人 アジャイル開発チームのプロダクトオーナー(ビジネスサイド、企画者） プロダクト開発チームが所属している会社の経営者 アジャイル開発を新たに学びたい人 アジャイル開発をひととおり知っているが、あらためて学びたい人 「正しいものを正しくつくる」という中心理念 本書のAmazonレビューを見ていたところ、星1つのレビューを見つけました。 エンジニアの傲慢さが詰まった本 「正しい」という言葉を使うエンジニア、同じエンジニアとして非常に恥ずかしい思いです。 「正しいも
bliki: Value Object
When programming, I often find it's useful to represent things as a compound. A 2D coordinate consists of an x value and y value. An amount of money consists of a number and a currency. A date range consists of start and end dates, which themselves can be compounds of year, month, and day. As I do this, I run into the question of whether two compound objects are the same. If I have two point objec
bliki: Anemic Domain Model
This is one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we've both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing. The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
ググるのをやめるとプログラムの生産性が上がるかもしれない - メソッド屋のブログ
今日はプログラミングの生産性に対して気づきがあったのでシェアしてみたい。 なぜ米国の人は生産性が高いのだろう プログラミングの生産性に関しては以前から興味がありいくつかのポストで考えたことをシェアしてきた。私は職業柄、いろんな国でいろんな人々とプログラミングを一緒にする機会が多い。その時に頻繁に感じるのは、平均的に言うと、アメリカの人プログラマが生産性が高い確率が高くて、しかもコードもきれいだという傾向にある。アメリカでお客さんと一緒にコードを書くと、お客さん自体が物凄く良く知っているし、実行力もある。アメリカの次と言うことでいうと、英語がネイティブの国もそれに近く、フランスなどの言語が近いところが続く感じなので、英語が物凄く影響すると思っていたし、実際すると思う。そのあたりの話はこちらのポストに書いてみた。 simplearchitect.hatenablog.com 定義での理解と、例
Adam Drake
Enough with the microservicesTl;dr:Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services. – Martin Fowler If you can’t build a well-structured monolith, wha
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
改善失敗して学ぶ、
レガシープロダクトに立ち向かうチーム作り。
The competitive edge of DevSecOps - Highlight