This article has completely misunderstand the term, mobile first it's the technical way of organizing the CSS to render the mobile viewport first and then the rest of the 'breakpoints'.
Mobile-first design has the advantage, over the desktop-first design, that it directly render first the mobile design and the cellphone experience is much faster and with less rearragning flickering.
Mobile-first doesn't have the corresponding disadvantages at the desktop browser since they tend to have a land line internet and much faster cpu and memory.
I have created a vuejs components library that is based on a proprietary js framework.
Its super easy to create a new component since all the JS and design is handed from the proprietary framework, and i have full control on the complete library.
The downside is that i have to create every component i want to use and i cannot share the library with anyone.
Like some of the sibling posters, I'll use this opportunity to share my feelings on Ada. I checked it out a few years ago, and I was amazed at how much it has to offer. Despite being designed by committee in the late 70s, Ada has many features that remain novel by today's standards. I'd say Ada is a 'must see' for anyone interested in implementing new programming languages, there are many great lessons language designers can take away from Ada.
It was also heavily negatively influenced by C++. If you like reading lots of hilarious ideological, syntactic, and semantic ranting and raving about how terrible C++ is, pick up one of Bertrand Meyer's original Eiffel books (from before Java, which is another negative reaction to C++ in a different direction), you'll love it!
Where I think it broke down is with multithreading, because you can't reason about preconditions and postconditions of a method if there are other threads banging away at it. But maybe that's been solved since when I read the Eiffel book.
Sather is an open source language that was originally based on Eiffel, but developed in its own direction. Named after the Sather Tower at Berkeley instead of the Eiffel Tower in Paris.
One benefit I had from learning Ada was that it treats encapsulation, implementation hiding, inheritance, subclassing, message passing, etc. as separate mechanisms that you can opt into individually.
This is a huge difference compared to something like Java or Python where "everything is a class and a class is everything", and if you desire implementation hiding you sort of automatically also opt into get encapsulation and subclassing and the rest of it.
When you learn the mechanisms individually, object-oriented programming starts to make a lot more sense! Ada is worth looking at just for that experience alone! Then the other things are a bonus.
This connects to another of Ada's advantages: language-integrated support for
subsetting the language. In the C world, you can define a subset of the
language, but if you want a tool to ensure compliance, you're on your own.
With Ada, you can define a 'profile' and have the compiler check compliance.
This has been done with the Ravenscar profile (for real-time work) and, most
famously, the SPARK profile (for formal verification).
(There isn't integrated support for user-defined style guide conformance
though. From the perspective I've used here, MISRA C is both a subset and a
style guide.)
You can get going with the Alire package manager which installs the Free Software Foundations GNAT compiler (part of GCC) in a few minutes: https://ada-lang.io
Despite being designed by committee in the late 70s
You say that like it stayed there. Ada has been updated and refined continually since the first standard in 1983. Ada 2012 is the latest approved, and Ada 202x is in review.
Just like Fortran (see Fortran 90, 95, 2003, 2008 & 2018).
My apologies. I was only referencing the typical criticisms people have of the language. Most of which having absolutely nothing to do with the language itself. I'm very familiar with modern Ada. I've done lots of hobby programming in Ada 2012, and now Ada 202x.
You know what's a lot like Ada in a good way is Mesa, which evolved into Ceder, from Xerox PARC. I know people who really loved programming in it. They'd call it "Industrial Strength Pascal". It was a successful experiment in code reuse. A strongly typed language with strong separation between interfaces and implementations, which encouraged creating robust, hardened code.
>Mesa and Cedar had a major influence on the design of other important languages, such as Modula-2 and Java, and was an important vehicle for the development and dissemination of the fundamentals of GUIs, networked environments, and the other advances Xerox contributed to the field of computer science.
Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)
Mark Weiser and others at Xerox PARC's ported the Cedar environment to Unix, which resulted in the development of the still-widely-used Boehm–Demers–Weiser conservative garbage collection.
I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it.
Experiences Creating a Portable Cedar.
Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser.
>Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the performance of our "Portable Cedar".
PCR implemented threads in user space as virtual lightweight processes on SunOS by running several heavy weight Unix processes memory mapping the same main memory. And it also supported garbage collection. Mark Weiser worked on both PCR and the Boehm–Demers–Weiser garbage collector.
>Similarly, we treat any data inside the objects as potential pointers, to be followed if they, in turn, point to valid data objects. A similar approach, but restricted to procedure frames, was used in the Xerox Cedar programming environment [19].
[19] Rovner, Paul, ‘‘On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent Language’’, Report CSL-84-7, Xerox Palo Alto Research Center.
My guess is that the BDW garbage collector had its roots in PCR (pun intended, in fact this entire message was just an elaborate setup ;), but I don't know for sure the exact relationship between Cedar's garbage collector, PCR's garbage collector (which is specifically for Cedar code), and the Boehm–Demers–Weiser garbage collector (which is for general C code). Does anybody know how they influenced each other, shared code, or are otherwise related? Maybe there's a circular dependency!
This says “developed after the Star“ but imho the Dandelion (marketed as the star) was too slow for this environment and you needed one of the bigger machines (Dolphin or Dorado).
Actually it’s kind of amazing to realize that two years later youncould get a small Mac for about a fifth the price that sat on your desk (not rolled next to it on casters) and was much more responsive. Did less, but what it did it did well, and was all that most people needed.
In addition to the Smalltalk and Mesa environments mentioned in the post, there was the Interlisp-D environment too, which got much more use outside thanks to being used outside PARC.
pjmlp on Sept 13, 2020 | parent | next [–]
The Computer History Museum organized a session with Eric Bier, and several other folks demoing the Mesa/Cedar environment.
The only modern environments that seem to have kept alive several of these ideas are Windows/.NET/COM, the ones designed by Apple/NeXT and to certain extent Android (although with a messed up execution).
Even Linux could grasp many of these ideas, if D-BUS would be properly taken advantage of and settled on a specific development experience.
Somehow it looks like we are still missing so much from Xerox PARC ideas.
----
The Cedar Programming Environment:
A Midterm Report and Examination
Describes Portable Common Runtime (PCR), and the PostScript and Interpress decomposers implemented in Cedar, and includes many other interesting document about Cedar.
I wish more language designers paid attention to how Ada did things. The language has some features that are very relevant to performance that even C++ or Rust lacks.
For example, Ada allows to return stack-allocate arrays with variable number of elements. One can emulate that in C++ with various arena classes, but the resulting code is not that efficient and the usage is much more complex.
My only real exposire to Ada was a report for a class project in college. One tidbit that stuck with me is that there were a few DOD projects using Ada after it was first created which actually got done ahead of schedule and under budget. That always impressed me given the normal DOD software track record.
Also, I believe people place way too much emphasis on "popularity" of a language. If a language has enough traction to stay alive it can be valuable unless you're doing the most generic web dev stuff around. Heck there's cases where Perl still outshines modern competitors.
I’ll shout out for ADA as well. Really enjoyed working with it.
Compiler was a nit picking monster but the rigour ensured that you really considered your program. Thanks for making me remember.
I offered a job in a company that implements NATO procedures.
Its a company in Greece that implements radar software for airspace among other defensive projects.
I stayed there only for a month, i hated the objective of the job, I hated the UI custom library, I hated the way I had to test my code, I hated how much of disengagement I had to do from my morals to work on 'defense' projects.
You need to find the type of RC receiver on the plane, and the protocols it speaks, and the type of radio/transmitter you have, and the protocols it speaks. A common controller/radio/transmitter brand is FrSky with the ACCST protocol (apparently now ACCESS), Flysky with AFHDS2A, and Spektrum with DSMX. Each of these brands and protocols has their own binding procedure described in the transmitter and receiver manuals. Since this article is about inexpensive, the least expensive, well-known brand I listed here is Flysky. Frsky is more about open source and modularity, and Spektrum is the most American but not cheap or open. Radiolink appears to be another large brand but I don't know as much about them.
Generally, all of these are about sending a PWM signal, with the pulse width being 1.0 ms - 2.0 ms, where 1.5 ms is the "center" position, at an update rate of 50 hz, to represent the controller stick positions, with 4 channels, two for each axis of two sticks, and perhaps additional channels for communicating more data from a fancier controller to a fancier receiver for things like flaps, landing gear, flight modes, etc.
I don't really see what FrSky did as shady - they introduced a new system with DRM that was not compatible with their old system, which was widely cloned. They did a really poor job at communicating these changes and explaining the implications, but I don't feel that there was anything malicious about it - just a matter of poor documentation. Their main competitor at the time (TBS) also has extensive DRM on their system, they just haven't yet had to deal with 1:1 clones.
Anyway, you're right that ExpressLRS appeared to eat their lunch, especially now that it's approaching legality in many regulatory regions. ELRS is really a very strong open source story - a hack project appeared out of nowhere and managed to disrupt a whole cottage industry by virtue of being community built and supporting a wide range of implementations.
The shady part was not them releasing their new ACCESS system. But releasing stupid "critical" (not really) firmware updates to their ACCST 1.x systems, that were backwards incompatible with their own systems. At one point users couldn't even find the older firmware for their own hardware, and had to download it from 3rd party backups on Google drive etc.
It seemed like they always took that one extra step to make life more miserable to their own users. Inverted ports for sbus (that were a pain for telemetry on F4 processors). Kept releasing so many protocols (D8, ACCST 1.x, ACCST 2.x, R9, R9 2019) and new hardware that didn't work well with their own older hardware, just to stick it to "1:1 clones"?
I used to help out a lot of newbies with this hobby and half the issues I have had to help them with were just the Frsky compatibility issues.
You'd need a really strong reason to not use ExpressLRS, especially when coming in new. The Wifi flashing, binding phrase, "power pellet" receivers, and (in ELRS 3) Wifi-connected Betaflight (no more USB!), are space age technology compared to the previous generation.
There's a lot of details missing from your question I think. I tried doing some brief research for you because the question sounds interesting, but without knowing information that would narrow down the quality of the remote or the plane, it's too difficult to guess what your next steps are.
Look at the docs for the radio on the plane and then acquire a remote control that is compatible with that radio. Or, if you don't even have a radio, buy a remote control and radio, read the manuals, install the radio (and battery), connect the servos, check that it works.
You would be right if it continues to be proof of work. More miners would mine more ETH.
But this is not the case, the 'mined' ETH will come from proof of stake. Some people with more than 32 ETH and an online server will keep the engines rolling and get 5% in return for their service.
The less power is because the electricity is used for serving instead of mining.
It's an odd way to see a shop leaving my app!