I think part of the problem with IoT firmware updates is that so many companies are rushing to get v1.0 of their project out the door that it's very difficult to even think of v1.1 or higher. Agile development and Lean Business practices, as practiced by many organizations, can often encourage this short-sighted behavior. So updating gets punted on because it's _technically_ not necessary for the first version, and it's definitely not one of the "cool" core features you get to put on the glossy marketing website for the device.
I completely agree—hope the article communicated that.
Although I think the ideal experience is one where its completely automated and out of mind for the user, I do think the next best thing is to turn it into more of a glossy, marketing-friendly competitive advantage. Something like "better peace of mind through enhanced security" or some other nice-sounding soundbite.
IoT security is a huge concern for me personally, especially in the wake of the Dyn attack. I'd love to see more strategies for helping make things better, especially in the consumer space.
One thing Caret gets right that other Markdown editors (Macdown is what I currently use) don't is wordcount. In Caret, the document wordcount is always visible in the upper right corner, and if I select some text, the wordcount for the selection is displayed again. Others have mentioned the lack of live-preview as a deal-breaker, but I'm ok with this because of the easy, obvious shortcut. My main purpose with Markdown editors is writing READMEs and blog posts, and I usually don't keep live-preview open as I'm writing.
The one missing feature to keep me from pre-ordering is detection of jekyll YAML headers.
I'm with antback on this one. You write as many words as are needed to convey your message. Unless you are a journalist or a student, why does it matter?
Also, if you're serious about word count and other metadata about your document then you should look into Marked 2. It's got that and much more.
Reading this article leads me to believe the writers at Techcrunch are slowly discovering basic economics, and they think it's revolutionary.
Instead of selling “software-as-a-service,” these DIFM companies are
delivering “software-with-a-service.” The result is awesome customer
experience that can only be delivered with a human touch.
Techcrunch has it reversed. These companies are selling a service, and happen to effectively use software to create their competitive advantage.
As a daily bike commuter around Boston, this idea terrifies me. Multitasking is extremely dangerous while biking. There are already enough bikers out there who choose to distract themselves with earphones and music while biking. Reading a text message while weaving in traffic is a recipe for disaster. When you're on a bike, be on the bike.
I am a daily bike commuter in Anchorage where we have tons of dedicated trails. I can ride all the way to work 7 miles and I only have to cross a couple streets.
This would be fine. better than pulling my phone out of my pocket while riding (which is what I do now)
I'd like to see the author make an attempt with the React library [1] in PHP as well. You don't have to abandon your language of choice to gain the ability to do asynchronous I/O.
One of the assumptions made by this article is that the user in question is loading your web page with jQuery on a mobile device running on a 4G network. In reality, however, it is unlikely that a user will be on a 4G network. In 2004, the 4G penetration is 25% in North America, and only 3% in Western Europe. [1] It's certainly growing on a yearly basis, but it's still not at the point where you can rely on users having 4G speeds on a mobile device.
The 4G worst-case scenario is still better than the best-case scenario for a 3G network, which is what you'll see with a majority of users. I'd like to see this analysis done with a 3G connection as well, because I suspect the real jQuery tax for a majority of mobile users is over a second.
I do like the point made about latency and the suggestions at the bottom of the article. It's a strong incentive for apps to introduce a real asset pipeline and js and css minifiers.
4G and 3G often falls back to Edge (or even GPRS with bad latency) in Europe. And with Edge you better make sure your JS file is smaller than 200kb (for a web app), otherwise your mobile user with Edge connection will have to wait some seconds (load time). jQuery itself is already 81kb (compressed).
1Mbsp == "worst mobile networks"? Maybe if your website is a social network for US millionaires :-P. What if your visitors are from around the world? Here in Croatia, we don't even have 3G in some parts of the country.
I like this concept - small, usable art installations designed to make inconspicuous things social. But the pessimist in me takes one look at their concept and things "That's going to break so quickly here in Boston."
What I would love to see, and which seems realistic from this video, is an installation that shows the people waiting a "loading bar" or countdown or some visual indicator of how long until the crosswalk is green for pedestrians. In the video they show this as the background color - red or green - gradually draining from the screen.
It's not really pessimistic at all. It's realistic. Putting video screens at hand level in public is just begging for vandalism. Doesn't matter how much chemically treated glass you layer on top, it will get punched/kicked/keyed/stabbed. Repeatedly. Look at how bulletproof the simple microswitch behind the "Press For Walk Signal" needs to be.
> That's going to break so quickly here in Boston.
Depends on what you mean by "break". In Boston, you might just get, epic, hour-long pong battles. Seriously, the pedestrian signal situation in Boston is so haphazard you could hardly make it worse by introducing experiments like this.
And building Twitter [1], and big-data next-generation databases [2], and android apps, and desktop apps, and big data [3], and as a platform for new languages (Clojure, Scala, Frege), and many more applications.
Really, the JVM can be used for anything that _computers_ can be used for, and it does so in a way that the code is runnable across all major platforms and still maintains a top-5 language performance spot, even beating C/C++ in some specific cases.
Why do you feel that the JVM is limited in its applications as a development platform?
If you say so, I see very few of these in production.
> and big data
Daemon.
> Why do you feel that the JVM is limited in its applications as a development platform?
You can't write cli applications in a JVM language because the start-up time is too slow. Which means you can't compose scripts that call Java apps.
This is not just 1 type of application, it's the most important type of application by far. It's fundamental to how Unix operates. With Java you can't write small applications that do one thing well, you have to write big applications that are going to run for a very long time.
This is useful for things like web servers and daemons, but otherwise it sucks. It's why I can't get excited about JVM languages.
> You can't write cli applications in a JVM language because the start-up time is too slow. Which means you can't compose scripts that call Java apps.
You're right. In the case of small, fast applications designed to be called as part of shell scripts, the JVM does suffer start-up costs. Some testing on my personal machine shows the JVM to be 2x to 8x slower than a comparable Ruby or Python script in startup time. [1] Depending on the script, that startup time may or may not acceptable, and if the script runs for longer than a second, which is entirely possible for anything that goes beyond the local machine, the JVM will get progressively faster.
> This is not just 1 type of application, it's the most important type of application by far.
This needs more explanation. I've used Unix for many years, and I've definitely bought in to its philosophy of small and composable; It's a philosophy that in many ways mirrors functional programming. However, in my opinion, the most important type of application varies considerably by person. For you, the small, single-purpose
applications may be what you use most.
And I agree, if you're programming for the Unix platform, the JVM would not be the best choice. Unix was built on C. A program that builds on that platform is probably a better choice.
But there are many more applications out there, and for any command-line program that operate in a time domain longer than 10 seconds, the JVM startup costs are mostly eliminated. This time-domain is very plausible for a command that operates on medium-scale databases or anything with network connectivity.
It's silly to completely dismiss an entire platform because it is not the absolute best choice for a single domain of programs.
I'm curious: What do you do where the short-lived, composable Unix functions are the most important programs?
I think we simply approach software different. I feel that small, composable applications should be the default, and I nearly always start off this way. I've been involved in projects from writing a specialized version of cp, ETL processes, to developer focused but consumer-facing web applications and the first interface I write to anything I do is as a small cli application that works well with standard unix tools.
When you embrace this philosophy it doesn't particularly matter how good a language's ecosystem is, you have all of unix to interop with. For example, I don't care if a language has a good JSON parsing because jq[1] exists and is probably faster and easier to work with than just about any language's built in tools, even better than JavaScript itself.
With JVM you can't participate in writing software this way. Everything must revolve around the JVM and it's ecosystem.
The original press release appears to be overloaded right now, but hopefully will come back online soon. At https://globalpressroom.bose.com/us-en/pressrelease/view/192...