Yes. So then the title is very misleading and should not be called D4.js.
150 karma · joined October 6, 2014
The part I question is, the percentage of programmers that will work at a "hard tech" company is so small that, unless the company you're working at is a hard tech company, then there is no relevance to onboarding someone with CS skills. It does not diversify the team. Diversification in a team is of high value. Most engineers want to hire others engineers so that they have something to talk about. But that's a comfort thing.
Long story short, soft tech companies should only have one or two hard tech engineers on their team especially in the early days and only test at the skill level required when onboarding.
Went from being Simple left to right, top to bottom style to some weird layout that it very hard to navigate.
I would give that sucker a grade of “F”.
Great reminder to have users test products before shipping something.
As well as use common sense in your designs.
b4 has a much stronger "foundation." What do I mean by that? Well to be honest if you actually look at the HTML structure of both frameworks, you'll see that b4 is not only utilizing more modern techniques but that they have reduced and simplified their markup. ie, navigation items. b4 uses <div>'s for each nav element which allows for more control while foundation is using an older technique of unordered list items.
This is just one example of how b4 takes a more wholistic approach to every aspect of their framework. I don't fault foundation at all and it probably has to due with the talent of the core b4 team as well as the massive community that they have, but I can't see a use case where I'd choose foundation over b4.
A couple of points that jumped out at me from this article.
"In our experience, BLE did its job pretty well on a number of projects."
Ha. I have yet to see BLE work consistently. Which brings me to my next point. This "could" be due to the fact that products I've seen implementing BLE are not pushing past the data transfer limits.
In the write up, they are claiming you can push past the standard 23 byte limit through "...a procedure called “Read/Write Long Characteristic Values” that allows you to go over the limit with a series of messages. In practice this means that you’d be able to have a transfer ratio of around 125 kbps (133 connections per second * 6 packets * 20 bytes in each packet – see “Getting started with BLE”)."
Would be very interested in seeing what sort of consistency an app could get out of this bump in bytes.