-
I’m sorry I don’t understand what this is. What would I do with this? Is this similar to like Electron?
-
-
-
because of the way it’s designed, as described in the talk. changing that would break way too much stuff, like libs which rely on linking to C in order to function.
one cool thing about Deno is that it seems like one could make a “codepen”-style JS code pasting/collaboration service really quickly, and not have to worry about sandboxing the code execution like you normally have to do. the fact that its package management works by using URLs makes it even easier. just
import React from "https://unkpkg.com/react-0.0.1/react.js"and you’re done. no messing around with package managers, no worrying whether it’s down, no worrying about depending on “yet another package ecosystem” if you’re coming from other places like Python or Ruby.
-
-
-
joshuacc
18 days ago
|
link
| on:
YES! I Compiled 1,000,000 TypeScript files in Under 40 Seconds. This is How.
Title is bit clickbaity, but the actual content is super interesting, too. :)
-
-
caryhartline
23 days ago
|
link
| on:
A New Dark Pattern: Tricking Browsers into Making Repeated Notification Requests
It’s a good thing that Firefox now allows users to preemptively disable all future notification requests.
So what is the end goal of this type of hack? I assume the assumption is that someone will just say “yes sure fine”, but then they could easily go into their system UI(?) to disable the notifications after they leave the browser. Notifications in browsers don’t exist in iOS so I don’t know the mechanism for how Android handles this.
-
-
djsumdog
23 days ago
|
link
| on:
A New Dark Pattern: Tricking Browsers into Making Repeated Notification Requests
I really hate browser notifications. I never click yes ever. It feels like preventing browsers from going down this hole is just yet another hack. The Spammers and the CAPTCHAers are fighting a continuous war, all because of the 2% of people who actually click on SPAM.
-
-
My firefox has that in the settings somewhere:
[X] Block new requests asking to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications. Blocking notifications may break some website features.
help links here: https://support.mozilla.org/en-US/kb/push-notifications-firefox?as=u&utm_source=inproduct
-
-
there always has been in Chrome and Safari and since very recently, there’s also one in Firefox. It’s the first thing I turn off whenever I configure a new browser. I can’t possibly think of anybody actually actively wanting notifications to be delivered to them.
Sure, there’s some web apps like gmail, but even there - I’d rather use a native app for this.
-
I can’t possibly think of anybody actually actively wanting notifications to be delivered to them.
Users of web-based chat software. I primarily use native apps for that, but occasionally I need to use a chat system that I don’t want to bother installing locally. And it’s nice to have a web backup for when the native app breaks. (I’m looking at you, HipChat for Windows.)
-
-
-
There is a default deny option in Chrome, takes a little digging to find though. But I agree that it’s crazy how widespread sites trying to use notification are. There’s like 1 or 2 sites that I actually want them from, but it seems like every single news site and random blog wants to be able to send notifications. And they usually do it immediately upon loading the page, before you’ve even read the article, much less clicked something about wanting to be notified of future posts or something.
-
The only time I have clicked “yes” for notifications is for forums (Discourse only at this point) that offer notifications of replies and DMs. I don’t see a need for any other websites to need to notify me.
-
-
I’m in my company office this week to pair program with my coworkers and some consultants on our new React and Node tech stack. While I’m here and have fewer family responsibilities to take care of, I’m going to work on more improvements to my personal productivity system, as well as a bit of writing on my current novel.
-
JavaScript tag?
-
“I’m thinking of a larger program of work in which an entire solution has to be designed and delivered, (more or less) complete. Such projects have distinct beginning, middle and end phases, all of which must complete successfully if the project is to succeed.”
AFAIK, that’s not really a thing to which one applies Agile.
-
Why not? My company just did this for a year-long project, and it has worked out spectacularly well. We are nearing the end of the project, and everyone is really pleased at how it has turned out and how well by-the-book Scrum[1] worked for the process.
[1] I prefer Kanban, but doing Scrum by the book is actually pretty good compared to Flaccid Scrum
-
-
-
(Warning: not an embedded guy but read embedded articles. I could be really wrong here.)
“This big push is causing a vacuum in which companies can’t find enough embedded software engineers. Instead of training new engineers, they are starting to rely on application developers, who have experience with Windows applications or mobile devices, to develop their real-time embedded software.”
I don’t know. I was looking at the surveys that Jack Ganssle posts. They seem to indicate that the current embedded developers are expected to just pick up these new skills like they did everything else. They also indicate they are picking up these skills since using C with a USB library or something on Windows/Linux isn’t nearly as hard as low-level C and assembly stuff on custom I/O they’ve been doing. I’m sure there’s many companies that are either new not knowing how to find talent or established wanting to go cheap either of whom may hire non-embedded people trying to get them to do embedded-style work with big, expensive platforms.
I think author is still overselling the draught of engineers given all the products coming out constantly indicate there’s enough to make them. Plus, many features the engineers will need are being turned into 3rd party solutions you can plug in followed by some integration work. That will help a little.
“developers used “simple” 8-bit or 16-bit architectures that a developer could master over the course of several months during a development cycle. Over the past several years, many teams have moved to more complex 32-bit architectures.”
The developers used 8-16 bit architectures for low cost, sometimes pennies or a few bucks a chip. They used them for simplicity/reliability. Embedded people tell me some of the ISA’s are easy enough for even assembly coding stuff to be productive on kinds of systems they’re used in. Others tell me the proprietary compilers can suck so bad they have to look at assembly of their C anyway to spot problems. Also, stuff like WCET analysis. The 8-16-bitters also often come with better I/O options or something per some engineers’ statements. The 32-bit cores are increasing in number displacing some 8-16 bit MCU’s market share, though. This is happening.
However, a huge chunk of embedded industry is cost sensitive. There will be for quite a while a market for 8-bitters that can add several dollars to tens of dollars of profit per unit to a company’s line. There will always be a need to program them. If anything, I’m banking on RISC-V (32-bit MCU) or J2 (SuperH) style designs with no royalties being those most likely to kill most of the market in conjunction with ARM’s MCU’s. They’re tiny, cheap, and might replace the MIPS or ARM chips in portfolios of main MCU vendors. More likely supplement. This would especially be true if more were putting the 32-bit MCU’s on cutting-edge nodes to make the processor, ROM, and RAM’s cheap as 8-bitters. We’re already seeing some of that. The final advantage on that note of 8-16 bitters is they can be cheap on old process nodes that are also cheap to develop SOC’s on, do analog better, and do RF well enough. As in, 8-16-bit market uses that to create huge variety of SoC-based solutions customized to the market’s needs since the NRE isn’t as high as 28-45nm that 32-bits might need to target. They’ve been doing that a long time.
Note to embedded or hardware people: feel free to correct anything I’m getting wrong. I’ve just been reading up on the industry a lot to understand it better for promoting open or secure hardware.
-
-
-
Yup. Jack Gannsle is always a good read. I highly recommend anyone interested in embedded systems subscribing to his Embedded Muse news letter.
Whether the Open Cores will beat ARM? Hmm. Arm has such a strangle hold on the industry it’s hard to see it happen…. on the other hand Arm has this vast pile of legacy cruft inside it now, so I don’t know what the longer term will be. (Don’t like your endianess, toggle that bit and you have another, want a hardware implemented java byte code, well there is something sort of like that available, …..)
Compilers? It’s hard to beat gcc, and that is no accident. A couple of years ago Arm committed to make gcc as performant as their own compiler. Why? Because the larger software ecosystem around gcc sold more Arms.
However, a huge chunk of embedded industry is cost sensitive.
We will always be pushed to make things faster, cheaper, mechanically smaller, longer battery life,….. If read some of what Gannsle has being writing about the ultra-low power stuff, it’s crazy.
Conversely we’re also always being push for more functionality, everybody walks around with a smartphone in their pocket.
The base expectation these days a smartphone size / UI/ functionality / price / battery life ….. which is all incredibly hard to achieve if you aren’t shipping at least a 100000 units…
So while universities crank out developers who understand machine vision, machine learning, and many other cutting-edge research areas, the question we might want to be asking is, “Where are we going to get the next generation of embedded software engineers?”
Same place we always did. The older generation were a rag tag collection of h/w engineers, software guys, old time mainframers, whoever was always ready to learn more, and more, and more…
-
This week’s Embedded Muse addresses this exact article. Jack seems to agree with my position that the article way overstates things. He says the field will be mixed between the kinds we have now and those very far from the hardware. He makes this point:
“Digi-Key current lists 72,000 distinct part numbers for MCUs. 64,000 of those have under 1MB of program memory. 30,000 have 32KB of program memory or less. The demand for small amounts of intelligent electronics, programmed at a low level, is overwhelming. I don’t see that changing for a very long time, if ever.”
The architecture, cost, etc might change. There will still be tiny MCU’s/CPU’s for those wanting lowest watts or cost. And they’ll need special types of engineers to program them. :)
-
Thanks for the inside view. Other thing about Jack is he’s also a nice guy. Always responds to emails about embedded topics or the newsletter, too.
-
-
-
I just turn my phone off / on silent / in a small lead box when I want to get on with work. Is this not a common sense solution if you find yourself becoming distracted?
-
-
On iphone (I don’t know for other platforms) you have a DND mode with “favorites” that can still notify you. I’ve been on-call several time and just setting SMS/Phone Call on first method of contact on pager duty + using this DND mode was enough for me to let my phone upside down the whole day and still be notified when I needed to be.
-
-
-
It seems to me like the problems with null all stem from the fact that it is implemented as a bottom type, not the fact that it exists at all. Are there languages that implement null as a separate type, and not a subtype of all types? Is there a good reason why most languages don’t do this?
-
Are there languages that implement null as a separate type, and not a subtype of all types?
At this point you’ve got option, because it’s no longer legal for a variable with type T to contain a null. Instead, to contain a null that variable must be of a union type T|Null, a.k.a. option a.k.a. maybe. There are lots of languages that do this (Kotlin, Swift, Haskell, Scala, Rust).
-
-
-
Yes, in .NET F# is a good example of this if you’re not interoping with C#. In C# we’re finally reaching a point where nullable reference types will no longer be the default and must be explicitly declared and will have proper compile time checking. It will be a warning by default for new projects, and you can also choose to make it a compile time error if you want.
-
-
The big annoyance was that back in the day, with posting boards and guestbooks being all the rage, (or just a badly made web page) people would open a blink tag and never close it and the browser would render everything after it on the page as blinking.
-
-
I remember doing that once in 1996. Good times.
-
-
-
-
It’s rapidly approaching the point where every blog post/tweet/article about JS development makes me just go “huh, wat?”
I used to work for an agency of sorts, and “custom” javascript (i.e. something more complex than can achieved by a few lines of bootstrap and some jquery plugins) was one of the things I became (one of or the, depending on timing) goto guy(s) for when projects needed help.
This concept of “we can automatically support browsers of ridiculous age, but choose not to” is fucking mind boggling.
Maybe the current frontend dev community is too many years removed from a true monopoly on browsers, (and hasn’t opened its eyes enough to realise the risks of the coming monopoly).
-
This concept of “we can automatically support browsers of ridiculous age, but choose not to” is fucking mind boggling.
But that’s not what is happening. Babel can provide automatic syntactic support for those older browsers. But it does not provide automatic runtime support. And it is extremely likely that one’s dependencies won’t support those older browsers. In most cases, the automatic syntactic support provides no actual benefit to the users of those older browsers, but does incur a cost to everyone else.
-
-
I… what? Why would you disable support for browsers when that support is automated? The mind boggles.
-
To reduce app size and download times. 4G LTE with unlimited data access isn’t ubiquitous.
-
I guess so. Seems like the size reduction would be pretty small compared to making the app better
-
Depending on the browsers in question, it can actually make a pretty significant difference. And if, for example, you are making a web app for businesses which has very clear specs about what browsers you are willing to support, you should definitely ship the smallest JS bundle possible for the supported browsers.
-
-
-
-
I think the elephant in the room that this article doesn’t directly address is “Do the programs you write have many types of data which should never be substituted?”. If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types. If by contrast you have many different kinds of integer that should not be mixed like weight and account balance you might really benefit from stricter types.
-
If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types.
I’ve yet to work on a useful program where the data’s representation as a “string” was the highest level of meaning that could be assigned to that data. As soon as you get past writing a toy you will start to have to differentiate between what different string values mean, and then we are talking about types–and arguably at precisely the point where we can start to leverage the power of a (good) type system. Speaking as someone who writes Clojure as his day job, it’s clear to me that this is why
core.typedexists, and why there is so much activity aroundclojure.spec(andschemabefore it)–it’s obvious that “everything is a string” (or in the case of Clojure, “everything is a map”) isn’t good enough to represent the kind of data we work with as professional programmers (and the jury is out on whether or notclojure.specis up to the task).So while that’s not to suggest that we always need a sophisticated type system–or that we aren’t sometimes hindered when forced to use a type system like Java’s–I think it’s fair to say that it is rarely, if ever, the case that we don’t have more meaning assigned to the values in our program above and beyond than their encoding as low-level storage representations.
-
I think another good example of this situation is algorithmic code - the structure one would like to express (e.g. sortedness, sub-solution optimality, graph acyclicity) is often beyond what the type system can represent. You end up with numeric arrays / matrices / edge lists without much further type structure.
At the opposite end is either unit-heavy code (as in your example) or structure-heavy code (e.g. configs / ASTs / requests), both of which significantly benefit from what a typical type system offers.
-
If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types.
Could you give an example of such a program? I deal with strings relatively often, but the bulk of the logic in my programs (client-side JavaScript) benefit quite a bit from types (via TypeScript).
-
-
Personal:
- Reviewing the the paperback proof copy of my fantasy novel
- Write some of the last remaining scenes in my horror/supernatural suspense novel
- Study of Getting Things Done by David Allen
Work:
- Training a team on React & TypeScript
- Heads-down coding on an AngularJS & TypeScript project
-
The imperative and declarative versions are, in two cases, semantically different.
Execute something on every element with map: the
for-loopdoesn’t do anything with the return value fromperformSomething, whereasmapputs the results into an array. Consider usingforEachinstead ofmap. e.g.array.forEach(performSomething)Finding a single element in the array: the use of a return in the
for-loopcauses an early exit, whereasfilterwill iterate through the entire array.Iterate over an array to count a property of each item: I can only nit-pick and say the declarative implementation as-written is more verbose than the imperative one. Please consider:
items.reduce((result, item) => result + item.content.value, 0)-
Finding a single element in the array: the use of a return in the for-loop causes an early exit, whereas filter will iterate through the entire array.
There’s also
Array.prototype.find().With regards to this improvement:
items.reduce((result, item) => result + item.content.value, 0)If you want to get (probably too) fancy with destructuring, you could do:
items.reduce((result, { content: { value } }) => result + value, 0)-
items.reduce((result, { content: { value } }) => result + value, 0)That’s clever, thanks I will include this example!
-
-
I’m still not sure what aligns to ES5 or ES6, but as per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find:
This method has been added to the ECMAScript 2015 specification and may not be available in all JavaScript implementations yet.
-
-
-
-
Good points, thanks for the feedback, I’m editing the post to incorporate it
-
-
zpojqwfejwfhiunz
2 months ago
|
link
| on:
How I've Built a Profitable Slack Bot as a Side Project in Rails
If you’re a Polish guy that looks like this, why would you lead with a stock photo of an asian guy in your article about yourself?
-
-
Continuing my productivity system improvements. Last week wasn’t as huge a success as previously, but I maintained the same gains despite several unexpected events which normally would have tanked my productivity. So, still success? :)
This week’s personal activities:
- Move my organizer’s sections around so that it’s closer to the recommended GTD layout.
- Make a weekly planning checklist so that I’m less likely to forget a step
- Follow through on some long overdue family records paperwork.
- Continue refining the family budget with YNAB.
And for occupational activities:
- Learning how to write a proper Jenkinsfile (I mostly work on UI stuff, so this is a little outside my normal)
- Get out of the weeds and do some proper planning of our UI architecture so that we’re ready for upcoming projects.
-
I’m continuing to work on increasing my productivity by implementing some basic systems. Last week was a huge success. I accomplished about twice as much as normal with roughly the same amount of effort.
The new additions this week are:
- A Filofax Saffiano A5 planner, which I have organized into a rough approximation of the GTD method.
- A weekly planning session where I choose a primary project and distribute it’s tasks throughout the week. Previously, I was rather haphazard about choosing which task to work on, so projects tended to drag on with only occasional progress.
My primary project for this week is to create a monthly budget with You Need A Budget.
-
FWIW, You Need a Budget (YNAB) is great. Definitely give it a few months though. And be sure to connect it to your accounts (just like Mint, read-only, it’s safe). Yes, it is great to get into the habit of entering everything manually - and you have to for cash. But the online connection helps immensely if you forget something. I’m at 1.5 years now and the difference has been HUGE. My ability to budget before was terrible and YNAB has saved my butt. Budgeting used to be last minute - now I’m months ahead and finally saving.
-
Also a huge fan of YNAB, been using it for just over a year now and it’s literally changed my life.
However, I’d argue against linking your accounts. If there’s anything that I forget, I catch it in my weekly reconciliation process, which is yet another good habit to build (doing a weekly review of spending, adjusting budget categories, etc).
To each their own I suppose! But the account linking just makes it slightly easier to not keep awareness of your transactions, which is against the point for my purposes.
-
I’ve never been part of a standup that hasn’t devolved into “make yesterday sound productive” competitions/drivels. I think there are a few causes:
So, to make standups more productive I’d remove Stakeholders, Managers, and Engineers from the meeting.
😉
Edit: I was being playful, but I don’t think standups are useful meetings… at all. The idea that you should wait until the next day to bring up that you’re blocked seems ridiculous to me. However, if I were to run them this would be the format.
Note how there’s no “what did you do yesterday?” Talking about yesterday would be strictly forbidden. Not only does it run a high risk of turning into drivel, but everyone already attended yesterdays standup, so it’s purely redundant information.
That very much depends on team context. I’ve worked on teams where that is mostly (though not always) true. And I’ve worked on teams where what people said they were going to do ended up varying dramatically from what they actually ended up doing.
During peak season for one of my company’s sub-products, the development team supporting that product is very likely to be pulled into debugging production issues. Occasionally a team member’s expertise is urgently needed by another team. And of course, if you say more than one thing in your list of intentions, if anything takes longer than expected, then the rest of your intended actions may or may not relate.
It’s important not only to communicate what it is that you are trying to do, but also what you actually ended up doing so that if the source of change is a problem somehow, that problem can be addressed.
Where does it say you have to wait until next standup to bring up blockers? The ‘What did you do yesterday, today, and what are your blockers’ is just a training exercise to get novices trained to bring up blockers daily. It’s to get people into a habit if bringing them up every day. Believe it or not, some people will struggle for weeks with blockers until they bring them up, or quietly fail. This is especially true for newer people in the field.