HN user
Let me rephrase that. A toaster is functionally simple, but designing, engineering, manufacturing, and creating a business selling toasters is not.
Also I'm making the assumption it is for profit since they started off with "I'm wanting to start a business"
To mix in with other's comments.
It's always good to have a target in sight, but building a physical product with no experience will be a long, expensive journey.
I make physical and digital products as a consultant, the first thing I tell entrepreneurs is get to your first prototype. Not even an MVP, just something functional with the core features. Some times these are partial prototypes that work out various sub-systems. In this case, the actuation mechanisms, the heating elements with power, digital / physical controls, etc.
After that, the real work begins. You need to get to a complete working prototype. The other thing I like to say is just because someone else has made it, or something similar, doesn't mean I know how to make it. It just means it's technically feasible.
If you start looking at the parts of the toaster, you need to electrical engineering, mechanical engineering, material science, embedded software engineering, probably some industrial design and user experience design if you get that far. Even user research if you want to better understand the user and market.
Once you get to a first iteration, and typically before, you need to engage UL and FCC, usually through third parties to start testing for certifications and engineering refinement. You also need to start engaging contract manufacturers to understand how to work within limitations of their capabilities and your design.
A toaster may seem simple, but I assure it is not.
Then couple all of this with legal considerations as mentioned in other comments and whether or not it's even a practical business model. This is quite a large endeavor.
But if you are going to do anything, start small.
I would disagree that example is a slippery slope, but more of a leap across a vast canyon.
Going from providing information and requesting an action, to making an automated decision and action, is much more difficult as you pointed out. Therefore I'd be very surprised to see this actually occur.
Are you being specific about the word darken? Because LCDs are design to either allow or block light. So technically an LCD can "darken" incoming light. But I think the point of inconsistent lighting from the environment would be the biggest challenge.
The best example of transparent display I've seen in production is:https://glas.johnsoncontrols.com/
But the material on that seems darker and I believe they use an edge light to provide higher contrast.
I think the distance from the eye, as well, would be difficult if you aren't doing some type of projection, like what is used in the the article.
Okay, I think this reply helps frame your stance much better. You are not necessarily proposing no C ever, but saying at least start a new project with a C++ compiler / IDE and if there are reasons to use C code or rules like "don't use dynamic memory allocation", when there is a substantial reason, then that is acceptable
On Arduino, from my experience, it is easy to run into memory constraints, especially when using dynamically allocated memory like strings. And I'm taking about both the flash memory for code and the ram for data, stack, and heap.
I don't think C is always a win, but to say to never use for new projects seems overly biased. Why is your opinion about C so strong? I am curious.
An 8-bit microcontroller where memory is constrained and all the vendor libraries are written in C, is a good example.
Your 32-bit ARM M3/M4 cores are probably crossing that line where the memory cost of using C++ is worth it, but I would say there are still real world reasons to use C.
Though I would love to see more microcontroller vendors (or any) support C++ or Rust as part of they HAL libraries, but I think you will still find C to be perfectly viable for the low cost microcontroller application.
This is geared towards qtquick (not widgets) applications, but to create a general theme you can use this pattern:
https://doc.qt.io/archives/qt-5.11/qtquickcontrols2-flatstyl...
Then before the engine is loaded in main.cpp call
qmlRegisterSingleton( QUrl(QStringLiteral("qrc:/Theme.qml")), "mycustomname.theme", 1, 0, "Theme");
Then in a qml file:
import mycustomname.theme 1.0
This allows you to do something like:
Rectangle { width: 100 height: 100 color: Theme.mainColor }
You can also do things like set the application font which would be done in main.cpp before the engine is loaded:
QFont appFont("NameOfLoadedFont); appFont.setPixelSize(16); QGuiApplication::setFont(appFont);
You would need to load the font, which you can do in the Theme.qml file:
property FontLoader someFont: FontLoader { source: "qrc:/locationOfFont/Font" name: "NameOfLoadedFont" }
I find your comment very similar in tone as the article: someone who is a interface designer that has had bad experiences with UX designers.
I think this is unfortunate, because I think UX design just a definition of the process that product (digital or physical) design was already doing, and now there is a common (though still evolving) language to be able to communicate the challenges of the full product design lifecycle.
To me UX is the superset for user centered design and User Interface design is a subset of it. They are both important. UX is not UI because they are not comparisons, but parts of the same thing.
Those are my thoughts and experiences at least.
From my internet researching a while ago the main difference, and why MLMs are legal, is that an MLM sells a product, whereas a pyramid scheme sells people. That is, you can make money solely by acquiring more people who pay to be apart of it, in a pyramid scheme.
I'm still not sure how I feel about MLMs. If it's actually a good product maybe it's not a bad thing, but when it is not, that's where it seems to get sketchy.
I think it really depends on what you want to do. If you want to work with physical systems, computation, or data-science, then I think engineering physics is a good path.
Where I went to college, all engineering physics majors concentrated (which is essentially a minor) in one of the other engineering disciplines (mechanical, electrical, civil, computer science, etc).
If you want to work on digital only products that don't utilize what you learn with a engineering physics degree, then you may want to consider another degree.
I can't speak directly about a physics only degree, since I did engineering physics, where I took all of the same core classes as engineering students.
Motivation, experience wherever you can get it, and knowing people / networking, will get you pretty far, so I would also say, take the path that's interests you the most. Also, physics is hard.
I have a degree in Engineering Physics where I concentrated in Electrical Engineering. I also minored in Industrial Design. I currently work at a product design firm as an "Embedded Systems Engineer", where I primarily design and write software for embedded microcontrollers and microprocessors and couple that with user experience design.
I have been able to utilize my understanding of physics to work on things like designing sensors into products that require real world math (motion, position, motor control, etc), though not as extensive as it could be if it were academic research. And have used my circuits foundation to understand how to get answers in the realm of embedded micros.
The thing I emphasize the most though, is understand where you want to have an expertise and make it happen, work on it. Mine is embedded software with a user focused design process.
Fresh out of college, your degree is not going to separate you unless it's coupled with experience from internships, school projects, or personal projects.
My opinion is that a degree in engineering provides foundation, but real world experience is where you grow and learn for your career.
Side note: You mentioned "other than learning code", I think that is a valid option to supplement this degree. I started writing code in eighth grade, so it was something I was already doing and interested in. I never wanted to be a plain ol' software developer, so this path was good for me.
TL;DR Went to school for Engineering Physics, I am happy with my career path, but took it upon myself to find a way to provide value beyond the name of my degree.
Unfortunately this comment is conflating two ideas.
Nothing in this article conflicts with the idea that a UX designer knowing how to implement their designs in code would be a benefit.
I don't see a problem with the author (and others like myself) wanting the tools to be more capable.
Have you developed a design system? Do you understand the context of this domain? I don't ask this to be rude, but the issues that the author mention are some of the key problems with the state of being able to maintain design systems.
It's more about the ability to efficiently generate and document the design intent and iterate on the design. This then needs communicated to the full team, whether that's stakeholders or the team implementing the design.
I think the authors suggestions are very good and valid.
Mainly because of the extensive Hardware Abstraction Layers (HAL) libraries available from most mcu vendors
I am excited to see this come out:
https://www.nordicsemi.com/eng/Products/Low-Power-Cellular-I...
Seems promising, but I don't see the current consumption documented anywhere yet.
It would not be more signal.
https://en.m.wikipedia.org/wiki/Wave_interference
The goal of noise canceling is to fully use destructive wave interference to create a 0 amplitude "signal", which is no signal at all.
Depending on the application, I'll use a Finite State Machine pattern, but if I need something more complex I'll use QM QP/C (which is uses a hierarchical state machine pattern).
So it's good to see others using Quantum Leaps RTOS. It take a little bit to set up the environment and understand some of the bounds, but I really enjoying using their QM Modeling tool[1], I would recommend it. I would mainly use it for the logic and abstract out the code in separate files, so that you are not maintaining code in the GUI tool.
What I assume IncRnd is referring to is the deterministic behavior of an RTOS. Here is a good white paper from National Instruments:
Software is so complex that nobody really understands it.
Unless this statement is trying to imply something deeper than what it states, I would disagree.
I work with embedded systems and connected devices. To me it's not a problem of complexity, but a problem of not having a strong standard of practices on both the device side and the facility side.
Have sensitive data on your network? Separate it from the rest of the network, or don't put devices on the network that don't meet your security needs.
Is running software/application in the Linux environment deem it a derivative work? Does Honeywell have to adhere to a GPL if they aren't modifying the Linux kernel?
It's not clear to me that they would need to follow GPL.
Though we do have 4K tvs now.
I would actually say it is more of a game engine, especially when compared to three.js. Babylon.js supports physics plug-ins and collisions. They also have an action manager and other useful built in methods. Their tutorials are a really good place to start: https://doc.babylonjs.com/tutorials
Since babylon.js is more of a library, though, it doesn't have quite the tools to that something like Unity has, but they have great documentation and community support, and have a nice playground for testing small snippets. If you find an issue and post a question in the forum, I've gotten a fix in a matter of hours.
Note: User of babylon.js
Fair enough, his description seems misleading. To me a pixel is a discrete RGB value, which is made up of physical components, for example:
From the article:
"Asking someone what the size of a pixel is is a good way to confuse him or her because it’s a trick question. A pixel has no size, no physical value or meaning outside of its mathematical representation. It is a part of a relationship between the physical screen size, expressed in inches, the screen resolution, expressed in pixel per inches and the pixel screen size, expressed in pixels. Laying it all out, it looks like this:"
"As you might have noticed in my explanations, “Resolution” stands for PPI, in this case “109” but not “2560x1440”, like you might commonly see everywhere on the web."
I know it's picky and this article is trying to be simplistic, but pixels do have a physical size. That is why there are optimal resolutions, starting with a 1:1 representation of physical to software.
Edit: Actually the first paragraph of "Resolution, pixel and physical size" kind of really causes confusion, since he is trying to redefine standard definitions, and then tries to provide reasoning for the redefinition. This is mainly a note of caution.
Good Display is a Chinese Vendor that seems a little more transparent.
http://m.good-display.com/products_list/&pmcId=160&productCa...
You can buy a demo kit which features a STM32F1 and source code. You can also buy individual screens.
I've messed around with the demo board a year or so ago.
A friend and myself were talking about this exact same thing the other day (he works in the web / desktop app space and I work in the embedded space). We were working on an embedded project a while back and he didn't like seeing "bit magic" sprinkled throughout the code and I completely agree.
I approach this issue in 3 different ways: #define what those series of addresses and values mean, have a function that calls each one semantically, or a function that wraps all of them (what OP is doing).
I was going to show an example specific to this, but unfortunately ST did a poor job this time documenting this specific init sequence. If you look at those application notes linked in the tutorial, they just state they are mandatory private registers, which is disheartening. Looking at the example code that ST provides with their Nucleo boards for the evaluation kit of this module, it doesn't shed much more light, except that it seems to be something to do with ranging, tuning, and up-scaling of the data. They have two functions VL6180x_RangeStaticInit() and VL6180x_UpscaleRegInit() that call this sequence, depending on if up-scaling was defined.
Software for Nucleo Board for the VL6180X: http://www.st.com/content/st_com/en/products/embedded-softwa...
At this point, if I was actually working with this part, I would contact a ST rep and ask them what is up, because it seems weird they are forcing you to write to "private" registers.
If you look at the OP's code, you will see that he does wrap this series of code with VL_InitDevice(), and since ST does not have it documented any better than "These settings should be applied in this order with no substitutions", this is what you get. Doing what is suggested, I don't think really gets you much further, imo, but does condense your code, for what it is worth.
They also have QNX.
Agreed. The drop shadow needs to be swapped between the two.
I've recently been using Crank Storyboard and I've been off to a good start. You can run it on embedded devices like ARM Cortex-M series processors, or Linux, iOS, Android, Windows, with openGL support. It does require a license though.
http://cranksoftware.com/storyboard-suite
Also someone else mentioned Phonegap and using HTML/JS. I think is a good option but it depends on what your app does and if you're doing mobile app design.
I have not used QT yet, but after doing some research, it's kind of a pick your poison type of choice, IMO.