|
Maximilien wrote: Not the best time to go see Mickey Mouse.
At times like these, reservations aren't flying off the shelves...
Sorry, too soon.
|
|
|
|
|
Backups? What is that?
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
One of my colleagues lives in Venice, FL and the other is in Orlando. The owner (Venice) escaped South to Islamorada and the other is expecting wind damage/power outage but they are boarded up and should be able to handle it. Looks like I get a day off tomorrow! Either that or I will be the only one answering my phone!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
We evacuated from Tampa to Georgia on Monday, before the gridlock on the 75 started. Now we just hope for the best news tomorrow, Thursday!
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
If anyone is curious, there is a Ham network organized in the area that offers free live streaming of their repeater traffic and throughout the storm. SARNET[^]
This system is a multi-repeater link that operates in Southern Florida, and at the moment there is a moron with a radio deliberately interfering with emergency communications. Teams are currently out with DF equipment to locate and arrest the idiot.
Will Rogers never met me.
|
|
|
|
|
What a complete idiot
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Lucky to be South of it, getting 40+ MPH winds, no rain. I did put up the shutters.
Tampa area still trying to recover from Helene. Kids got hit hard in NC, now back here for the winter just in time for this one. Luckly, they are South also.
About 5 weeks ago, I contracted with a tree outfit to trim a couple of large trees. One from a lousy neighbor's tree that hangs over my yard, the other an oak that was approaching my roof.
They showed up today, couple of the neighbors assumed that I had called them in because of Milton. Just a coincidence. Glad to have it done though.
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
Richard Andrew x64 wrote: Sunshine State (Florida)
Perhaps the good people of Florida should change the branding of their state. One never hears about the sunshine in Florida, only about the bad weather.
I hope everyone comes through this storm safely.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Just saw this video this morning (safe for work), and it's worth noting that in Windows 11 24H2 Explorer apparently links to Recall.
Of course, their PR blah, blah says you can disable it (for now), but it's the whole frog slowly boiling thing going on. If it records your entire screen, you'd think there would be no reason for Explorer to link to it directly... unless it's also doing other things we don't know about.
Will I install 24H2 personally? Probably. Will I make sure I keep up with Linux if this gets worse? Damn right I will.
Food for thought.
Jeremy Falcon
modified 24hrs ago.
|
|
|
|
|
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that:
- an Analyst Programmer needs to have a good understanding of both the business and the technology/systems
- by "best", I mean most efficient.
This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers.
Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception.
But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But...
His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs.
Remember... this just MHO.
modified yesterday.
|
|
|
|
|
I know a guy who's completely into the technology, but has no eye for businesses.
He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation."
Well, maybe not that bad, but you get the idea.
Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product."
That was way to simplistic according to him.
I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time.
Because I've worked with many developers who are like that I'm for the duo.
An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together.
They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either.
It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone.
Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
|
|
|
|
|
The spec I just received sounds like it came from your guy. In a nutshell, it was:
- Remove hard coded Customer Type from routines A and B.
- Hard code Customer Type in routine C.
There was literally, no explanation as to why/what the problem was - and not one example. The coding took about 15 minutes. I then asked him for pointers on how to test - and this is what I got back: "The Customer Type is incorrectly set to 'X' which results in the wrong value in the transaction".
Sander Rossel wrote: Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other. and sometimes they're right!
|
|
|
|
|
Years ago I worked on a sub-part of a business application, that was written in Assembler. When the spec came over from the Analyst(s), it even told us which registers to use at each step.
|
|
|
|
|
I worked with someone like that Richard, his specs were so good/detailed/accurate he might aas well of coded it (and he could of).
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Yeah, been there done that
Sometimes I just ask "what are you trying to achieve?"
And if they'll say "that customer type is not hard coded."
I'll follow up with "and how does that affect the outcome?" or something like that.
|
|
|
|
|
I've worked with people like that; they get completely engrossed in the detail to the point that they can't see (or explain) the bigger picture.
|
|
|
|
|
Oh yeah, but this works two ways!
As a developer I've sometimes been kept from the bigger picture.
For some reason, people sometimes see us as idiots who wouldn't get it anyway.
Probably because we're to up in our technology.
Now that I'm a manager myself I always try to get a tour of the factory (if applicable) for me and the programmer(s).
If it's not a factory I at least try to explain the overall process, like "we get document A in an email and after that they open our software and do X and Y so at the end a price is emailed back to the customer".
|
|
|
|
|
A small part of my job is to provide support for customers. I avoid get into implementation details, but I don't shy away from trying to explain, at a high level, why things work do they (or don't) either. I never try to sound condescending however.
I think most customers appreciate the fact that I don't treat them like idiots. At the same time, I don't "go deep" as I would with my developer coworkers.
It's a fine line.
|
|
|
|
|
Same!
I even have a customer who asks me about it and says he appreciates that I take the time to explain it to him in simple terms
|
|
|
|
|
There are a lot of confusion between job titles and what they should actually do.
The Analyst Programmer will/should be responsible of the technical aspect on how to implement what the business analyst wants (after talking to the clients... )
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I've been a solo developer in a small company for almost 25 years and I've hardly ever worked from 'specs'. An exception was the last web application that just rolled out a few months ago where the customer provided spreadsheets (order sheets) and said 'Make it look like this.' They also provided sample invoices and reports.
The project took around 9 months to 'complete' and so far (knock on wood) has been the best product rollout that I've ever been a part of. I attribute that mostly to the customer knowing exactly what they wanted and working from sample output/reports. We also had weekly teams meetings during development which I hated, but were essential.
Typically, our customers/end users have very little input into our product's designs. For the most part, our products are very niche and everyone on the team has > 20 years experience working either directly or indirectly in that niche. Customers rely entirely on us to make something that works. If they come up with a good idea, we steal it then charge them for it!
For the most part, there are no specs...we just make it up as we go.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
xkcd: University Commas[^]
Two questions:- Any UNICODE experts here?
- If there are, are there different code points for each type of comma?
This is what occurs to you when you wake up with the start of a migraine and you are working "chemically enhanced".
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: are there different code points for each type of comma?
Gnome characters says no.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Comma, comma, comma, comma, comma chameleon
You come and go, you come and go
|
|
|
|
|
Software Zen: delete this;
|
|
|
|