National Instruments hosts a very handy table for finding IPC 7351 equivalents to JEDEC and IEC package names.
I’m linking to a local PDF version for convenience.
Hybrid applications seem to be gaining traction now. In what follows, I’d like to present thoughts on an alternative to the emerging standard hybrid app architecture.
The conventional hybrid architecture
In this model, which to the best of my knowledge is used by Electron, NW.js, and others, the user interface is rendered as HTML using whatever HTML, CSS, and front-end JS frameworks you desire. The use of Web technologies for the UI is an explicit goal of this architecture.
The UI is tightly bound in a one-to-one relationship with the app engine.1 The app engine is implemented with a Web back-end technology, typically Node.js. The app engine makes system calls through the engine’s baked-in features or through generic
child_process.exec()-like calls. This means custom and platform-specific behaviors that the app may require will need to be implemented as external
child_process.exec() callable units.
This architecture does a good job of leveraging Web technologies to create secure conventional desktop apps. In addition, frameworks like Electron and NW.js have matured to the point that developing hybrid apps that use many desktop app conventions is relatively easy.
An alternative hybrid architecture
In what follows, I present what I believe is a more flexible approach to developing hybrid apps—one that requires more carefully considered design but that yields greater flexibility.
In this model, the tightly bound user↔app engine connection is replaced by a REST API. Thus the app engine becomes a REST server, possibly embellished with some needed superpowers for accessing host resources. When the app interface is API driven, any REST client technology can be used for the interface, including HTML/CSS/JS clients, native mobile clients, terminal clients, etc. In addition, the client need not be local, making remote-controlled apps almost trivial to implement. Adequate measures must be taken to assure secure and authorized communication with the REST server.
The other change in the above model is that the REST server is implemented in C++. When this is the case, interacting with the host system can be done directly using a wide range of C++ libraries written for this purpose. The choice of C++ here is somewhat arbitrary; it can be any language that supports ready-to-roll support for the system manipulations that your app requires.
The two changes outlined above are decoupled—meaning that either can be adopted in the absence of the other.
One downside to using C++ (or Java, or Python…) for the server part of this approach is that the server must be able to run on the host platform. This isn’t a significant issue with desktop deployment: only recompiling the REST server for each target platform will be required. But it does currently present a problem for mobile deployment as few mobile platforms provide native support for C++ and its oft used libraries. If you plan to target mobile apps, implementing a REST server in a more universally supported language will likely be required.
Follow updates on my wiki.
1. I’m using “app engine” generically here, not as a reference to Google’s App Engine.
It’s not just me. Phoronix is reporting on growing concerns in the Qt community about the project’s increasing commercial focus and apparent deprecation of its open source core.
I have said many times in these pages and elsewhere that I really like Qt: it’s the right tool for a lot of jobs. But increasingly I’ve been feeling that any contribution I make in educating users about Qt is benefiting a commercial enterprise and not a community tool. So much so that I am re-surveying other open source multi-platform libraries to use as an alternative to Qt.
If the community no longer has meaningful Qt ownership, a lot of users will no longer be interested.
It’s a little early and so I may regret posting this, but I will do so anyway.
The Verge today is carrying a piece by Walt Mossberg that argues nothing is really open or really closed so, meh, don’t worry about it y’all ok? Because AppleGoogleMicroplex has your back.
His premise is that the debate between open and closed is false because the terminology is fuzzy. I’m pretty sure Walt is smarter than that. His premise is a festering pile of FUD.
For quite some time now, operationally valid and accepted definitions of “open source software” and “free and open source software” have existed. There’s no fuzziness in the terminology—if you understand the terminology. People involved in open source software have different motivations and philosophies for doing what they do, and this have led to different licenses that confer different rights and responsibilities to the licensee. They essentially break down into two camps: restrictive open source, where you must share all of your code modifications and derivations, and permissive open source, where you don’t have to share anything (but you might be required to attribute the original source with a copyright notice or similar). Both permit use in commercial projects.
Supporters of restrictive open source often strive for platforms that are fully open. Many powerful voices in FOSS today advocate for a computing and technological ecology where the user (the owner) has full and complete access to everything the device can do. They advocate that everything the device can do be documented completely in published, independently buildable and vettable source code and that the user (owner) should she wish be able to change any aspect of what the device can do to fit her needs or desires.
In the realm of communication devices, many advocates (myself included) feel that open access to software needs to extend to the radio units, GPS units, etc. And some (myself included) feel that hardware designs should be open source as well.
Thus there is no fuzziness in what people who engage with software development and those involved open source software movements mean by “open”. There is some fuzziness in application because those who advocate for completely open platforms are constrained by the products that are actually available (which are often built by those who use “open” tools only as leverage in their closed operations).
The other source of fuzziness is the straw-man FUD injected into consumers’ minds by articles like Mossberg’s.
“Open” can have several levels of completeness. However, there is nothing open about a house you buy that gives you access to only one or two rooms and lets you decorate them using only pre-approved designs that come out of an approved catalog. Confusing that with anything resembling “open” is the a serious bastardization of the concept.
About a week ago, I posted on G+ my concerns regarding the impact that Microchip’s purchase of Atmel might have for the Arduino ecosystem. Turns out I’m not alone, judging from the comments in the post from the Arduino folks that followed the same day.
Communities build incredible product loyalty, and open source (in addition to its other benefits) is an incredibly easy way to build community. Here’s hoping that Microchip realizes this and leaves a good formula alone.
I’ve added a bunch of modules to my KiCad library. These have not yet been vetted, so approach with caution. Here’s what’s new or changed:
- New library mfk-ipc-7351-diode.mod with:
- mfk-SOD3716X135N (SOD-123 diode)
- New library mfk-smd-not-ipc.mod with:
- mfk-fairchild-SOT23 (Fairchild version of SOT-23)
- mfk-fairchild-SOT23_213 (as above but with “BEC” pinout)
- mfk-fairchild-SOT233 (Fairchild version of SOT-233)
- mfk-fairchild-SOT23_2313 (as above but with “BCEC” pinout)
- Changes to mfk-ipc-7351-transistor.mod:
- Deleted mfk-IPC7351-trans-SOT65P210X110-6N_10mil
- Changed silk width in mfk-SOT65P210X110-6N (SOT363) to 10 mil.
- New part in mfk-vishay.mod:
- mfk-Vishay-TSOP341xx-alt (alt version of mfk-Vishay-TSOP341xx)
- New part in mfk-keystone.mod:
- Added mfk-KEYSTONE-621
The Arduino team have just released a new 32-bit board that targets IoT. Read about it here.
So there I was scratching an itch when I realized the scratch would make for a good Arduino library.
AsyncTimer lets you create a timer that does something when you start it (or nothing if you prefer), then waits a predetermined time before doing something else. While it’s waiting, it doesn’t lock up your Arudino the way the
delay() function does—it just schedules the time-out action to take place some time in the future.
If you’re not the RTFM type, you can just get what you need from the GitHub repository.
If you’ve opted to use a general-purpose IDE for Arduino development, perhaps in conjunction with a Makefile, it’s helpful to know what directories to point your IDE toward to get decent code completion.
To that end, I’ve added a list of the ones I know about to my wiki.
I have been evaluating WebKit and Blink-based open-source browsers for Linux—mostly because Firefox is often noticeably laggy on an old laptop I like to use. (I still <3 you though, Moz!!) Chromium is an obvious option, but I would like to investigate solutions that don’t rely on Google. This has led me to Midori and QupZilla. Both position themselves as lightweight alternatives to the big kids. Both have their pros and cons.
A con with QupZilla that I want to take on in this post is the result of its use of Qt. I love Qt. It’s the right tool for a lot of jobs. But it harbors a hidden gotcha when it comes to rendering web pages: you are at the mercy of the Qt maintainers’ web rendering engine update policies. The latest version of QupZilla that you can build with the production version of Qt (5.5) uses QtWebEngine, which is based on the Blink-based Chromium. (So much for not relying on Google!)
The current Qt release bases QtWebEngine on Chromium 40—which is almost a year old; the next Qt release (5.6) will base QtWebEngine on Chromium 45—already three months old. The version of QupZilla provided by Debian sid (unstable, rolling release) uses the deprecated QtWebKit, which in Qt (5.5) is based on Webit 538.1.0. This version of WebKit is already a couple years old.
A similar situation exists with Midori. It uses GTK’s WebKitGTK+, which in Debian sid is as of this writing at 2.4.9-2 and also is about about two years old. Probing the user agent indicates it uses WebKit 538.1.5. But as there is in Qt, there is an additional wrinkle in the GTK+ world. There are currently two versions of WebKit for GTK: WebKitGTK+ and WebKit2GTK+ . Depending on which one your GTK+ application uses, you may get an old or a new version of WebKit. The version of WebKit2GTK+ that ships with Debian sid appears to provide WebKit 602.1 at the moment, which is the current point-release WebKit, and new releases of WebKitGTK+ flow regularly. (Why Midori doesn’t use WebKit2GTK+ is a question for the developers and one that I hope to pursue. FYI, GNOME’s Web, née Epiphany, uses WebKit2GTK+.)
Whatever the specifics may be in this case, the takeaway is this:
When using integrated application frameworks, you need to be aware of versioning limitations with third-party tools that they bundle.