Hypothesis: empathy is the skill most effective at taking vague, poorly specified requests from customers and clients and transforming them into a design with well specified requirements and a high level plan to implement the design. For example, what a customer says they want often isn't what they need. Empathy is how we bridge that gap for them and deliver something truly valuable.
Given empathy is all about feelings, it's not something models and tools will be able to displace in the next few years.
Very much so. Pretty much all of these protocols are simplifications of asn1 and in some cases (like protobuf) there are a handful of things that got lost because the wire formats didn’t have them as they didn’t need them. A schema indicator being the single biggest flaw in protobuf.
If you parse a serialized protobuf byte array without having a .proto file, you have no way to dustinguish a byte string field from a nested message field. Thus you have no way to know how deep your parser should go.
Semi-related, one of the `imessage-exporter` contributors provided a great write-up on reverse engineering the handwritten and digital touch message protobufs [0]. The reconstructed proto files are [1] [2].
iMessage uses a very strange amalgamation of typedstream (message content), keyed archives (app messages, sticker data), and protobufs (Digital Touch, handwriting) for different features. I wonder what motivated all of those design decisions.
This is stuff is such a PIA to parse. I assume it's just different teams doing different features over the years, and being alternately repulsed/seduced by each format. Probably features are implemented as libraries so there isn't a master oversight - they aren't trying to make iMessage's internal formats follow a consistent plan, just let all the libs coexist...
Maybe they should be repulsed, considering all of the journalists that are getting persecuted and/or murdered because they are getting pwned through iMessage serialization bugs :)
I understand the overall feeling but I’m not sure I understand the specific reason why you say this is making code bases more terse. Are you comparing this with the alternative of using GCC specific extensions or no definition of likely/unlikely code paths at all?
Massimo this is great. LoRa client support and maybe also an Arduino LoRa Gateway it will be amazing for rolling out nodes in agriculture. These areas are often not served by existing networks so a DIY-solution will always have its spot.
There is a Shield + Gateway coming out soon , the Lora Alliance will use it as a dev kit. In the summer we'll have a MKR format board. SigFox is good becaue it can deliver now on a lot of use cases
A couple years ago, for a RHoK event, we imagined a network of seismic/motion sensors using cellphone brains on top of poles that could be dropped from planes and penetrate enough in the soil to remain steady and signal land movements before landslides.
This could be a really cool way of deploying (or dropping) a network with a mesh backbone.
Amazing work. If you take a look at latex please consider also XeTeX for its beautiful font support. It can give a lot of satisfaction when packaging good content. Microtype is also nice if one sticks to pdflatex.
Really an amazing job. Keep feeding your curiosity, it is really worth it and try to travel a bit while explaining your project. Array processing is something that deserves a better look. Many SDR solutions still lack a bit under this point of view. Yet that will be quite useful to have. :)
Even this paragraph is just a general description of what could potentially be a FEM analysis and some optimisation algorithm associated with that. Interesting result on the other hand.
