1,632 karma · joined May 4, 2012
- https://docs.onion.io/omega2-project-book-vol1/omega2-intro.... looks amazing
which I found researching and filtering in Mouser's embedded computing -> system on module page
- https://eu.mouser.com/Embedded-Solutions/Computing/System-On...
Perhaps I've been deceived by how "simple" the schematics for the Pi compute module look, and overconfident after my first experience designing PCBs. There doesn't _seem_ to be that much (that I would need) actually routed on the pi compute module (hdmi, audio, etc, etc, etc)
I always seem to forget about NXP family of chips, but indeed NXP seems to do an amazing job of supporting their products and pricing competitively.
Again, my sincere thanks <3
Nice juxtaposition using a name of a space faring craft for a deep ocean sub.
We run rubocop (including a handful of our own custom cops for enforcing US-english spelling, and some specific "remember to use a transaction here") only on changed files (using codeclimate)
That means as we gradually touch more and more of our older code, we slowly enforce the styleguide.
We don't run a lot of custom configs globally (none, I think) and disable selective overzealous cops on specific lines, or blocks.
Some notable annoyances are `def Something()` which is named this way to model it after the coercions in Kernel, which rubocop complains about because of the pascal casing, and a couple of cases of too-long-lines in long, long, long doubles/mocks in rspec specs, which is a separate problem of its own.
Our use-case is offline-editing of documents with an eventual sync-with-yourself-online. It's mostly there as a sync tool, not as a p2p colalb editing. Unless you count yourself as a peer, I guess!
We store a document in local storage which is the result of `Automerge.save(automergedoc) => serializable string`. That can be loaded with `Automerge.load(s) => doc`.
"Changes" are a first-class concept in automerge (makes sense, I guess) so you can do
before = Automerge.from({..some doc..})
after = Automerge.change(before, "optional commit msg", (doc) => doc.hello = "world);
Those `[changes]` are what we try and send to a server and keep them in a `Set()` for each document (background sync, service worker, etc make a nice experience.
This is all wrapped up in Redux, and a middleware that captures the changes, and a reduxStore subscriber that puts the document back into local storage after any changes.
It is for the application programmer virtually transparent, and so far we've yet to find a fault with it.
I'm sure I'll come to regret making "changes" my principle data type, as the server implementation just sees serialized blobs of data, and has no concept of the structure of the document. That's solveable if I need it ever, because there's a protcol compatible implementation in Rust, and I could always use the JavaScript one on the server too, just haven't needed yet.
The serialization is also quite large, in the order of kilobytes for what are actually quite small docs, but they do contain the original commit messages too, and the Automerge team is planning to release an optimized serialization format early this year, which they say will be especially useful for fields with lots of changes, such as text fields, which currently pay a heavy toll in terms of tracking `[changes]`. Fortunately that also doesn't affect me.
I can also +1 some of the advice to keep your whole document in a CRDT. We use React+Redux, but since React Hooks made stateless functional components a reality, we felt it was appropriate to use React exclusively for the UI state, and track only document states in Redux reducers. It feels light-weight and sustainable, although we're only about a month and 5k LOC into the project. Time will tell I guess.
[~/code/dotfiles]$ tree -a -R -L 2
├── aws
│ └── .aws
├── git
│ ├── .gitconfig
│ └── .gitignore_global
├── .gitignore
├── .gitmodules
├── gpg
│ └── .gnupg
├── README
├── ssh
│ └── .ssh
├── tmux
│ ├── .tmux
│ └── .tmux.conf
├── vim
│ ├── .viminfo
│ └── .vimrc
└── zsh
├── .oh-my-zsh
└── .zshrc
$cd ~/code/dotfiles
$ stow -t $HOME git
.gitconfig -> code/dotfiles/git/.gitconfigThe sizing and color options, the simple way some small things in the UX works to make grabbing a postit fast, and coloring it correctly was really, really surprisingly nice
Looks like the STM32H7 supports one MIPI CSI-2 peripheral (and/or one MIPI DSI).
Another comment on this thread mentioned on the back of this module are two long flat board-to-board style connectors.
Our technical terms to some extent do need to be gate-kept against having their meanings watered down, but I've seen so many "realtime" browser projects, that I'm afraid we have to accept it has entered into the common vernacular like "serverless" has, in spite of the inaccuracies.
And, the way all of those things work is by setting registers so that they're visible in the software either _still_ in a register, or mapped into the address space.
Edit: I checked your profile and see that you're an embedded engineer, so I must have missed some nuance in your question, because power glitching the boot sequence to mess with hardware init it a really popular vector for attacking embedded devices. Please feel free to disregard my reply.
Remote work being a set-back is possibly a side-effect of how I selected my new gig, but it has suited me so well, I don't care about the (temporary) career stagnation.
Beautiful story, I felt it hard.
I could also imagine that having a breaker in the house for a high amperage circuit which is regularly toggled-off is just a good safety precaution against the neighbors stealing your power!
I checked some examples in the playground and they seemed to be devoid of any kind of accessibility tags, and the generated HTML sources didn't look super friendly to screen readers.
For non German speakers, the taxi unions sued to restrict either zone, or number of vehicles back in April and won.
This article is about that being overturned by a higher court and allowing MOIA to extend the fleet from 200 to 1000 vehicles.
There's a paragraph in the article dedicated to "massive criticism from the taxi drivers" where the chairman of the Hamburg Taxi association says:
> ...The aim of the VW subsidiary Moia is to replace as much of today's public transport by private offers...
That implies that he thinks Taxis are a public transport, but of course, they aren't. Taxis have no affiliation with the city to my knowledge, save for some regulation.
Hamburg has an excellent multi-line metro network carrying millions of passengers per day and taxis are prohibitively expensive here. A taxi from my place to the airport, a < 10 minute drive is easily over 30 EUR, with MOIA (if serviced) it would be something like 85% cheaper.
Quite, which is why I'm both writing a book, and developing tooling to help with this problem. ES/CQRS is a nice pattern that you can explain to someone on the back of an envelope in 5 minutes, but the devil really is in the details.
This seems like the classic half-way that people take when adopting ES without buying into CQRS.
In my experience you need a minimal amount of historical knowledge about an aggregate to validate business rules, and that is strictly orthogonal to ways you may want to build projections over the data.
If I understand OP correctly they are saying that rather than deriving state by consuming their events, they were maintaining a kind of snapshot that served as both the read/write model representation of a given aggregate in addition to storing the events.
It can be very, very tempting to try and reuse "models" in both parts of an application, but some basic scrutiny and some hard-won experience will lead to examples such as how.. in a view model for a User there's almost certainly no need to ever consume PasswordChanged type events, but in the write model (business logic) you may need to consume not only the newest state (to compare for authentication purposes) but maybe some kind of analysis over time of how frequently passwords have been changed recently. This asymmetry is a bit contrived in this case, but I'm sure OP has similar examples from their own codebase.
In reality I have found that at most a handful of fields on otherwise quite rich models ever end up being "rehydrated" in the write model, and rarely ever as dumb attr setters; in the read models by comparison the vast majority of events recorded against any given aggregate end up being used by one projection or another.
I wonder how this made it to the front page, and what we are supposed to take from it other than "company lays people off after assuring them it wouldn't, employee wasn't given much notice and online accounts were locked out during the dismissal call" all of which, in my experience on both sides of the table is completely normal.
It is standard corporate hedging and damage control, and it doesn't make it right, but it is pervasive.
> Even if both the client and the server supports the same compression algorithms, the server may choose not to compress the body of a response, if the identity value is also acceptable.
I've actually run into this twice in my career and it has been a surprise to those around me in both cases. Both times in the context of small payloads where the server is applying some heuristic about whether to encode or not. (e.g status page stops sending gzipped output when the server is becoming "unhealthy")
[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...
we have to split our "collaborating" to google docs, and our "carving in stone" in JIRA and Confluence.
I'll say though that the "suggested edit" and "comment on a range" features (and the distinct edit modes about commenting, suggesting and approving edits, and free for all battle royale are all valid modes for us all the time.) (300 person SF+intl. software company)
Absolutely, at the risk of bike shedding, for a German/English speaker this parses really strangely. The parent comment nailed the problems I have looking for another missing consonant.