|
Calin Negru wrote: You don’t get to hear on news such things.
You think the mainstream media care to report anything like that, when there's perfectly good politicians that need to monopolize all the talking points?
|
|
|
|
|
Mainstream media have many issues with reporting science news. I remember when an experiment resulted in particles traveling faster than the speed of light: media clamored that we finally discovered thae speed of light is not the theoretical maximum velocity particles can achieve.
The experiment reached some infinitesimal percentage of light speed faster that lightspeed and the report clearly stated that it was probably an error in measurement and that they would check the test equipment: turns out it was exactly that, a slight clock misalignment between source and destination. Media didn't care one bit.
I also got in a huge argument with my parents about it where they threw a bunch of names at me when that was my first reaction as well. Never apologized when I was proven right for the same exact reasons I pointed out in the firts place.
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
|
|
|
|
|
Every bit of SVG parsing C code I've seen
1. Expects the XML to be loaded as a string into memory
2. Constructs an in-memory representation of the basic XML document (parsing floats, and enums and such, but essentially a similar parsed tree as the XML)
That's not good on an embedded device. The minimum size of a practical SVG is about 10-20KB. I've seen them over 100KB easy.
So I have to rewrite this code to peephole parse, which I've done before but ran into stability issues in that code I think? I can't be positive because my backtraces were being blown up.
I'm trying to process it mostly top-down, rendering as I parse to reduce memory requirements, even though it still requires certain things like CSS styles to be kept around.
I have an XML peephole/pull parser that I wrote and works well enough, so that part is good, but I don't know the SVG spec that well. I've mostly just ported other people's code to make it go.
The other issue is I can't use the STL, and it would definitely make my life easier.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I might be off again, since I do not know how these vector files reach you, or if you author them yerself.
What if you have a chance to pre-process the files on a real computer? There are some "binary-XML" forms out there.
Or if you are creating the vector image? There is the lightweight: TinyVG[^]
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I've considered preprocessing but many of these devices are connectible and you can't download SVGs if I don't support them. I don't know how big of a deal that is in practice, probably not much, but it would actually be a lot more work for me. I have codebases I'm pulling from, mainly a nanosvg port I completed for gfx 1.0, and plutosvg so I have quite a bit of the work more or less done, waiting to import and massage.
If I switch to another format I have to redo all that code.
TinyVG is interesting, and I'll keep it in my back pocket, until I hear that someone's actually using the format, as this is the first I've heard of it.
One of the advantages of htcw_gfx is you don't need to preprocess most things. You can get your screens directly from your designers in SVG, PNG or whatever, and simply put them on the display. This saves time, especially when you have a lot of assets. It also makes the build process simpler since you're not doing any preprocessing of assets.
So all that said, I like being able to support formats as they were intended, where possible.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Years ago I read the book, The Art of Doing Twice the Work In Half the Time[^], by Jeff Sutherland (one of the 17 signatories[^] on the original Agile Manifesto)
The original 12 principles [^] were great guidance (not a methodology).
Anyways, that book was really good & offered A Methodology (SCRUM) that could be used by Companies to create a (paraphrase) "system for creating software which was flexible.") But of course companies took it and made it so Legalistic that it devolved into garbage.
Of course, Agile (which is different from Agile Scrum) & Scrum have both been so altered by so many consultants and books that none of it means anything to anyone any more.
If You Read Nothing Else, Read This Quote About Agile (or watch the video)
I was watching this 9-year old video of Allen Holub and he makes this statement (click here[^] for the moment he makes the statement in YouTube video)
Allen Holub "By the same token, Agile requires constant feedback and constant interaction with users which means that an actual end-user of your software must be in the room while you are developing. If you're not doing that, you're not doing Agile."
My Reply
Well, then, glad we had this little talk. No one is doing Agile, then.
POLL: The Big Question
Have you ever been on a project where the user actually sits in the same room (or even building) as the developers?
I've worked for numerous companies for >33 years in IT & I've never seen this done. Ever.
I can't even remember having an actual user in the same building for a half day.
Have you ever been on a project where you've had a User's time 100% of the time during the project -- the entire time the project is being developed?
Steve Jobs : iPod
The story is that Steve Jobs wanted 1000 songs in his pocket. Yes, we could probably consider him the User and he had Ultimate Power & Authority and so he was able to drive to a product like that.
Netflix? Spotifiy?
Yes, there have probably been some "developer-driven" projects like that (Netflix? Spotify?) but they are so ridiculous that they should _never_ be held out as examples.
Summary
Agile is 100% fake.
Multi-Headed Hydra Monster
The only way it isn't fake is because it is a Multi-headed Hydra Monster.
Every time you hack one of the monster's heads off (Scrum[^] begone!) another head grows back SaFE Agile[^].
modified 9-Sep-24 15:56pm.
|
|
|
|
|
raddevus wrote: Agile is 100% fake.
100% true (IMHO) at least in the form it is usually practised.
raddevus wrote: Have you ever been on a project where the user actually sits in the same room (or even building) as the developers?
Yes, many times. It was less practical for users to come with their equipment and ship/boat to my office so I would go out and spend a few days/weeks at user's site/boat/ship writing the program based of his/her feedback. I remember staying on a ferry between Hirtshals (Denmark) and Oslo (Norway) for a whole week writing a navigation program. That was way before ECDIS[^] systems were almost everywhere. I would take breaks while sailing through the Oslo fjord because it is so darn beautiful 
Mircea
|
|
|
|
|
Mircea Neacsu wrote: Yes, many times.
!!!!
Was this specialized hardware? Or extremely custom stuff or something?
What was the product (in general, if you cannot speak about specifics)?
Very interesting.
Do you think this would work -- be possible -- for most software? I mean, "i've never seen users that want to have to provide more than a few sentences before they are bored and ready for me to go program it."
|
|
|
|
|
It was mostly data acquisition software for hydrographic and dredging work. It had to connect to different hardware like GPS, echosounders, tide gauges, etc. It is a rather narrow field but the program was not custom made; just adapted to specific needs and growing by integrating those needs. In a lot of cases new users were very happy to discover features that have been requested by previous users.
Edit: Now I read your whole message 
raddevus wrote: Do you think this would work -- be possible -- for most software?
Most probably yes. The two requirements I see would be that A) the software can really help the user in his job and B) the programmer has the humility to accept that user is an expert in his field and not try to teach him how to do his job. Once the user sees that the program will really help him he will become very invested in its success.
Another story from the field: brand new dredging vessel in France with a bridge that looked like starship Enterprise with 20+ monitors for different systems. One of them was ours (and a rather smallish monitor at that). Captain that had worked with us to iron out all small issues was presenting the bridge to visiting officials and, pointing to our system says: "...and here is the jewel of the bridge, the system that shows how the dredging operation advances...". Needless to say I had a very warm feeling inside.
Mircea
|
|
|
|
|
Yeah, that makes sense to me for "specialized" application (probably expensive to pay for your time too, I'm guessing).
But I've never seen an instance of external software made for masses where they can sequester a user.
I could be wrong, but I've never seen it myself.
And I also know users -- they are so bored with IT / App Dev that they can barely speak two sentences about what they actually want.
I had internal users (tech support) who
1. drew a winform exactly as they wanted it
2. said the winform must appear in the app when the user holds the left button down. (As soon as the button is let up, the winform must disappear.)
3. This winform would display extra data that was displayed nowhere else (bec they didn't like to see a lot of data at once.
I made the winform look exactly as they wanted it. Even down to the colors they asked for.
THey said this functionality was extremely important.
I created a video of the functionality and asked them to watch it.
I never got any response that they viewed the video.
I finished the functionality and got a call from
tech support mgr 6 months later: "Where the hell is the data? Why didn't you put that feature in?"
Li'l ole Me: Uh, did you left click and hold it when you're on a row of data?
tech support mgr: Oh...
They don't even look at or use the functionality they beg for and design themselves.
There's no way they gonna sit in a room for months. No freakin' way!
|
|
|
|
|
I agree, there are users like that. For me, it was mostly when the "user" coming up with the requirements was a middle manager not the one really using the app.
raddevus wrote: Yeah, that makes sense to me for "specialized" application (probably expensive to pay for your time too, I'm guessing).
True, our software was rather specialized so people were motivated to have it working. And you guessed correctly, I was decently paid 
Mircea
|
|
|
|
|
raddevus wrote: Of course, Agile (which is different from Agile Scrum) & Scrum have both been so altered by so many consultants and books that none of it means anything to anyone any more.
It's amazing how many people don't know this. Agile (in the sense I know of it) can be implemented by Scrum, Kanban, or Extreme Programming (XP). And, I can promise you that most "consultants" don't know a damn thing about Scrum, etc. 
raddevus wrote: Well, then, glad we had this little talk. No one is doing Agile, then.
I didn't watch the full video, but IIRC to do XP properly called for something like that. It was the OG in Agile implementation. Thankfully, it died out like the fad it was.
But... few things to note...
1) Just because someone is able to give a speech doesn't make them the arbiter of truth. I mean maybe, but maybe not. People need to believe in something authoritative in a system humans agree on that seems authoritative... like giving a speech.
2) The end user isn't always John or Jane Doe sitting at home. In the enterprise an end user could mean the business. They are your customers since they are asking to you to make a product on behalf of the customers sitting at home. So, to that degree, the "end user" should be in a tight feedback loop.
3) This dude just might be one of those uptight dudes who can't evolve. I dunno. Maybe he's not. Maybe he's awesome. I didn't watch the video. But, Agile implementations have come a long way since the early days of implementations like XP.
raddevus wrote: Agile is 100% fake.
This is where most people get it wrong. Agile is a set of guidelines and philosophies, but it's not an implementation of said philosophies. To use OOP parlance, it's an interface. But, it ain't gonna do crap unless there's an implementation.
And guess what... all those implementations are not the same: Scrum, Kanban, XP, etc. Thus Scrum is not Agile and Agile is not Scrum, but Scum is an implementation of Agile principles. Which is to say, any hard rule would come from Scrum, etc. and not Agile. I dunno if that dude conveyed that in his speech, but if he didn't... I wouldn't trust him regardless if he has a microphone in hand.
So, Agile isn't fake, it's just guidelines and most people don't really know the difference. This is straight from the Agile Manifesto (which is way more authoritative than that dude):
- Satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development.
- Deliver working versions frequently.
- Bring business people and developers together.
- Build projects around motivated individuals.
- Engage in face-to-face conversation.
- Measure progress with working versions of the final product.
- Promote sustainable development.
- Pay continuous attention to technical excellence and good design.
- Keep it simple.
- Use self-organizing teams.
- Regularly reflect and review.
Number 4 is of particular importance, but that does not mean have some end user sitting over your back when you code. That's some XP nonsense that died off thankfully.
Jeremy Falcon
modified 9-Sep-24 17:47pm.
|
|
|
|
|
Wow! Great analysis. That guy, Allen Holub is still around and runs his own consulting company and still espouses the belief that "there will be a user in your dev room or else you aren't doing Agile".
He has written books and is a big deal in the "Agile" world.
The few seconds before he makes the outrageous claim about must have user, he says, "if you are working on any time schedule then you are not doing Agile." Interesting because all companies work on some kind of schedule.
I agree with the 12 Principles and like them for guidance in my own work.
I think it is all just guidance but I don't believe in the Agile thing written in books or spewed by consultants. That's all fake.
Again, great conversation. Thanks 
|
|
|
|
|
Unfortunately, charisma sells. And I get it, people like likeable people. But that's no guarantee they're correct. It just means they're charismatic. And it's not like the average person will do research. It takes a special person of high intellect IMO to do that.
And you're totally welcome.
Jeremy Falcon
|
|
|
|
|
Btw, if I had to distill Agile into a one liner it would be this:
Iterative development and tight feedback loops.
That tight feedback loop will remove the need for anyone standing over your shoulder.
Jeremy Falcon
modified 9-Sep-24 17:57pm.
|
|
|
|
|
I agree wholeheartedly. I think Real Agile (12 principles) is how "real work is done", because as I look at how I create software / manage projects myself those things all come into play when I'm actually driving toward a finished product. But, alas, many companies (even tho they may not know it) are not driving toward a finished product. They are just typing code.
|
|
|
|
|
Oh, I will say, there is one thing that XP popularized which is good and that is pair programming.
Now, XP says you need to do that all the time, but XP is garbage. Pair programming can be invaluable when stuck on a problem, training, etc. However, if 2 coders don't have any stuck issues it slows people down and code reviews make this pointless anyway. Assuming those code reviews / PRs aren't too large and far apart.
This comes from real life experience and being on and running teams. Not from a book.
So, pair programming is a tool. A great tool actually as it can save so much time. Just don't over do it.
Edit: Don't confuse pair programming with mob programming. I think mob programming is pretty awesome. I wouldn't do it 24/7, but I love the guy behind it (Woody Zuill). Met him a couple times... great guy and makes a lot of good points. But, even the dude behind mob programming will tell you, you don't have to do it 24/7. Do as much as you're comfortable with. You can; that's cool. But there's nobody with a hammer over your shoulder. It's meant to be fun and collaborative.
Jeremy Falcon
modified 9-Sep-24 18:32pm.
|
|
|
|
|
That's the problem I've always had with agile. Like you, in the 36 years I was active I never had 100% access to a customer. I could call occasionally to ask questions and clarify requirements but they were generally busy doing their daily work. They had limited time for me. Once in a great while they'd come to the office but usually for training after development or for requirements/kickoff meetings beforehand. But sitting in on Dev meetings or generally being there during development - never, not once. Not even during my last 3 or 4 years when my company was actually trying to switch over to agile scrum. They had their own jobs to do and those jobs ranged much further than just running our software. Heck, we couldn't even get them to install beta versions to tell us what they liked or hated no matter how much we begged.
|
|
|
|
|
Yep! That's exactly what my experience too.
This part of Agile (always having a user present) seems totally fake to me for "normal" applications.
I'm sure there are special cases like Nuclear Reactor software or something, but other software it just doesn't happen.
FreedMalloc wrote: Heck, we couldn't even get them to install beta versions to tell us what they liked or hated no matter how much we begged.
Yep, all of this is really just an intrusion to them. They don't want to play with your software which isn't the actual software they need to use to do their job.
|
|
|
|
|
raddevus wrote: POLL: The Big Question
Have you ever been on a project where the user actually sits in the same room (or even building) as the developers?
Many applications in our company (and many (most?) other financial institutions) are built by people sitting on the trading floor with the traders who are using the application. When an application doesn't work, feedback is instant. So in that sense I guess that aspect of agile is being adhered to.
|
|
|
|
|
Very interesting. Thanks for sharing.
I worked at a large mortgage company with 100s of branches and they attempted to re-write the Loan Origination system and they did not follow that idea.
They worked on it for about 5 years and spent $75 million then gave up and used none of the code.
It was crazy!
|
|
|
|
|
We have a sort of multi tiered version, in so far as the people building the applications are actually on the trading floor, but they are themselves users of the components they use to build those applications, and the components are built by a different team who are not actually on the trading floor (it's often noisy) but very close by, so the application builders can liaise directly.
|
|
|
|
|
My experience with stuff like agile and scrum is that people simply don't want it.
Developers do, management think they do, but users often don't.
One mistake is that people still think of it as a development methodology and so only developers get training.
However, it asks a lot from users as well!
And those users usually do not get the same training.
They just want to tell us what they want, preferably in one no too long sitting, and get exactly what they asked for (or thought they asked for anyway).
And it makes sense because to them the software isn't all that complicated or they only use a small portion of the software.
They surely don't want to see incomplete software every two weeks.
Releasing new functionality every two weeks is a myth, users want the full product or nothing at all.
Lots of users can't even see past incomplete software and it only makes them resist change ("see, you can't even do X with the new software!")
For all those reasons I prefer a more waterfall approach, it's simply more user friendly.
I'm not fleshing out all the details up front and we do have some meetings with users and there are regular meetings with analysts, but it'd be a stretch to call it scrum or even agile.
We're agile in the sense that we can always make changes even during development, we can shift priorities, we can do all that, but I'd still call it more waterfall than agile (as a methodology).
|
|
|
|
|
Totally agree with your entire post. 100%!!
So many things you said are so true.
Sander Rossel wrote: One mistake is that people still think of it as a development methodology and so only developers get training.
If you listen to the actual Agile people you discover that it actually affects the entire organization -- and if it doesn't then you are not actually Agile.
Sander Rossel wrote: They surely don't want to see incomplete software every two weeks.
Exactly! Users are annoyed by having to see partial software that doesn't do the parts they want anyways. They won't even look at it. Many times they won't even run the app once.
That has been my experience in every company I've worked in over 33 years.
Even as "Agile" has come along, it's really been waterfall with some agile ideas.
Thanks for sharing, really appreciate it, and very interesting to hear someone else say those things too.
|
|
|
|
|
<ChrisEvansVoice>Hail Hydra!</ChrisEvansVoice>
Software Zen: delete this;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
