|
ed, they make a pill for that.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
This is my daily workflow but I lost the hope for a ponytail, my hair are one by one removing themselves from the dumpster fire that is my head.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
I'm working through this right now[^]
Part of me is excited, as I made bootloader code back in the 1980s on much simpler processors, and no C language to speak of, only ROM basic or the "mini" assembler. This is a far cry from that, but similar in spirit.
Part of me is frustrated. I hate datasheets. I think the ARM TRMs are even worse. Give me code.
Part of me is sort of terrified that I may have overcommitted to a project going bare metal on an ARM Cortex A7.
But usually I feel that way going in - my imposter syndrome gets going and until I settle in it's me, nail biting.
My main problem is the utter gap in capabilities between the best ARM "realtime" core available, and the "non-realtime" As is so huge that I'm actually forced to adopt the A when all i really need is an additional 480MHz core.
I'm using STM32 because I'm more familiar with them, you can get cheapo nucleos for a lot of their realtime chips, and they have fairly priced modest eval boards for their A offerings. I also had a harder time trying to source the NXPs I felt i needed in general.
I was using an H7 for something and it just tops out under what i need for this application performancewise, so now I need to move to an A.
And that typically means an OS like Linux or Android. And boot times that go with it. I've seen ways to get boot times under 1sec but it's almost as arcane and messy as going bare metal.
So I've decided on baremetal for this application, on a dual core 800MHz A7. I need almost instant boot times, and it's hardware that really doesn't need all the moving parts of an operating system. Moving parts scare me. They don't tend to survive production runs.
It's kind of an array of bad choices. Part of the reason I'm laying this out to you, is you have way more experience and training in this realm than I do, so any insight would be appreciated.
Baremetal A7 is basically using the A7 like an ersatz realtime M. But it's not easy.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I guess you're not shaving your legs any more 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Anyone else using the Twillo Authy desktop app? I've just had a pop-up telling me that it will stop working in March. 
User guide: End of Life (EOL) for Twilio Authy Desktop app - Twilio Help Center[^]
And because they're so helpful, there is no way to export your 2FA keys to use in a different application. Because giving you access to your own keys would be a security risk, obvs. 
Except... there is a way, so long as you download v2.2.3 of the app, and prevent it from auto-updating itself:
Export TOTP tokens from Authy · GitHub[^]
I've just managed to import mine into 2FAS, which isn't a direct replacement, but looks OK for now.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Wow, while reading the wikipedia entry for Dependency inversion principle - Wikipedia[^] I stumbled upon...
The Inventor's Paradox[^], which states:
From wiki entry: "The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem.
Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought-after solution."
Very interesting, because this often explains why problems take longer than expected to solve.
You're actually solving an entire classification of problems.
This also made me think about the Spherical Cow[^] solution (kind of the opposite):
from wiki entry Milk production at a dairy farm was low, so the farmer wrote to the local university, asking for help from academia.
A multidisciplinary team of professors was assembled, headed by a theoretical physicist, and two weeks of intensive on-site investigation took place. The scholars then returned to the university, notebooks crammed with data, where the task of writing the report was left to the team leader.
Shortly thereafter the physicist returned to the farm, saying to the farmer, "I have the solution, but it works only in the case of spherical cows in a vacuum."
|
|
|
|
|
:cough: Scope Creep :cough:
Targeting a "general case" can be a slippery slope. It's not always a good thing.
|
|
|
|
|
PIEBALDconsult wrote: Targeting a "general case" can be a slippery slope. It's not always a good thing.
* If it's a one-off and you won't have to maintain it and it'll "just work", then just get 'r dun.
* But, if you will have to maintain it in the future and the customer will want changes and you'll be endlessly touching the code? Then you better get the general case right.
It's a freakin' paradox!! 
|
|
|
|
|
PIEBALDconsult wrote: Targeting a "general case" can be a slippery slope. It's not always a good thing.
Besides, agile principles says that you should never, ever, make any sort of preparations for future extensions.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: agile principles says that you should never, ever, make any sort of preparations for future extensions.
Which one[^]?
Oh, you probably mean Scrum, right? 
I only believe in the original Principles, not all the add-ons that were created to allow authors to make $$$. 
12 Agile Principles
1. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work
together daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
11. The best architectures, requirements, and designs
emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
|
|
|
|
|
raddevus wrote: Which one[^]?
In theory, there is no difference between theory and practice. In practice, there is.
A major reason why I asked to be moved to another project in my last job was that the project leader at several occasions made his corrections to my design, 'we do not have the resources to do that now!'. E.g. we were making a monitor, a minimal OS, for embedded systems, and in my proposal the request code was transferred in a register. The chip had an alternative software interrupt with an 8 bit request code embedded in the instruction. We 'didn't have the resources' to be prepared for more than 256 requests. So the design was changed to use the limited instruction. Less than a year later, the code range was exceeded, and software interrupts had do be rewritten to handle more request codes.
I had a couple other very similar issues where I had suggested solutions that allowed for extensions, that were rejected because 'We will cover the needs we have today, and that is it!' - and a year later, the simplified solution from the first round was replaced with my original proposal (or something very similar).
The project leader's rejection of more future oriented designs was fully supported by the majority of the development team. Avoid unnecessary complexity! --- As if transferring the request code in a register instead of in the instruction would lead to 'increased complexity'.
This is how I have experienced 'agile' software development in practice carried to its extremes. Thinking just a little bit ahead was like swearing in church; everyone who know anything about agility would try to silence you.
If you want to attach it to a single one of the principles, it would be 10. Simplicity--the art of maximizing the amount of work not done--is essential. Agile people, as I have met them, tend to live by the first part of Albert Einstein's pronouncement: Make it as simple as possible, fiercely fighting the second part, but no simpler.
I think this development group was at the extreme end. Yet I see a lot of the same in other environments. It was prevalent in internet protocols for the first 30 years or so - I wasn't the one pointing out that a lot of the protocols was missing a 'T': SMTP should be named 'TOO Simple Mail Transfer Protocol', SNMP should be 'TOO Simple Network Management Protocol', and so on. (I think SNMP was where I heard about the missing 'T' for the first time, and it immediately rang a bell with me.)
Theoretical agile principles are great for quoting at big celebrations. For practical work: Look at what people who claim to be agile are doing, not what they are quoting.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Great story.
My take-away is that "Good principles are always corrupted by bad people."
In your case, the Boss who has veto power but questionable knowledge nixes a perfectly good feature.
Boss has mentioned "Agile" somewhere along the line, so you attach the idea to this error-Boss.
Every Principle ever considered has exceptions and vast numbers of people who say the principle is a thing that it is not. So it goes.
It's why, in IT, I've learned that my motto is:
"Blithely I roll on." (see definitions 2 & 3 below)
wornik dictionary: blithely
adverb
1. In a blithe manner.
2. Without care, concern, or consideration.
3. In a joyful, carefree manner.
|
|
|
|
|
When I see the term "agile" I insert adaptive. Over the years of software dev. I learned that bottom-up and top-down usually occurs together, in tandem so to speak. One needs a big picture but one must also understand getting there from the bricks.
It's natural and wise to plan ahead, but not to an extreme. As the sign says "the future is tomorrow".
Also, from time to time, play the user as best as one can.
They are part of the target.
Don't know what this has to do with Spherical Cows,
but dogs run in circles because it is too hard to run in squares.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
trønderen wrote: says that you should never, ever, make any sort of preparations for future extensions.
I kind of like that one.
Because the vast majority of time the developer is coding for something that might happen 10 years from now.
Versus the much smaller and more reasonable case where they have seen a future Epic already broken down that adds an additional case. Of course the correct path in that case is to modify the current Story/Epic to insure it accounts for the future case.
|
|
|
|
|
Exactly… think of all of the software that was obsolete before Y2K so it never needed the updates!
|
|
|
|
|
Software being obsolete is no reason for not continuing to use it. I run a lot of obsolete software 
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Think of all of the software that will be obsolete after the year 9999.
No time like the present to start coding for that.
|
|
|
|
|
not our problem… Just wait a few hundred years for Mars Central Time Zone still with daylight saving time!
I hate time zones/DST and the fact that US legislators like to change them too often.
|
|
|
|
|
Myself the offset by 0:45 always annoyed me.
|
|
|
|
|
After solving a few specific problems in animation, I came to the "general conclusion" that the only things one needs to accomplish the full range of motion for a "shape", is x and y displacement and rotation (in 2D). A general solution has emerged that now drives all the others; "saving" time and mental energy.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Is the opposite of a Spherical Cow a Cubecumber?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
I know a company in India which is moving chips from general to particular.
They are designing chips for very specific purposes, almost with that particular instruction set (plus a small delta, maybe). They aim to lower memory and power consumption ... and more importantly, cost.
modified 13-Feb-24 22:07pm.
|
|
|
|
|
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference?
I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway....
So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so.
Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc.
Just like SVN.
Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me.
Appreciate your thoughts.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
