|
The only writers I bother with are the ones that limit themselves to HTML, CSS, and JavaScript; and rave about it. Mind you, I only have to answer to myself.
"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
|
|
|
|
|
Maximilien wrote: I'm overwhelmed with new technologies
I like the pocket guides and references by O'Reilly[^]. For me they're much better than the mammoth tomes that pass for programming books these days. The other problem with BIG BOOKS is that they are organized according to the author's bias to the material. Features that they don't like or don't understand don't get a lot of attention. Stuff they do like and understand they use only in their preferred style.
The guides provide a concise survey of the technology and its syntax. I currently have their books for HTML5, CSS, JavaScript, jQuery, HTTP, and SQL on my shelf. They occupy a little under 3 inches of space. If I need more detail or depth, Google[^] and CodeProject[^] are my friends  , and Stack Overflow[^] is a reluctantly, occasionally, and necessary evil  .
Software Zen: delete this;
|
|
|
|
|
I haven't had an issue with html, css*, or javascript/typescript, but I've never used Vue. Angular has some really good documentation in my opinion. I don't have much experience with React but it seemed... alright. There's a lot of "magic" under the hood though which was confusing since you absolutely need to understand how it works for all but the simplest tasks.
I feel you though. A lot of documentation seems to be written for the author rather than the reader. It's a problem I've run into with learning functional programming. Once you get past the beginner stuff, most of the resources are written for people that already understand everything. You have to have a Master's in type theory, set theory, group theory, category theory, nth-order logic, and more just to parse the terminology in a single sentence.
*: Except for layouts. Good lord, we have tables, box, flex-box, grid, etc and none of them aptly solve the issue without "clever" hacks half the time.
|
|
|
|
|
Jon McKee wrote: Once you get past the beginner stuff, most of the resources are written for people that already understand everything.
This is still a big problem sometimes.
|
|
|
|
|
Having lived through (and indeed taken a small part in) the development of CP/M, MSDOS, windows etc. I have long since adopted the philosophy of using dev stacks that run behind the pack. The number of times when I hadn't even completed a coding task only to find that some dependency had changed, or a library no longer worked the way it did before (or even got completely broken by some update - Hello Borland!? Anyone there?) are too numerous to count.
For my recent web/mobile apps the only framework I have used has been Bootstrap, and that only because it is both so long in the tooth and so widespread it is at least fairly mature and has at least some chance of being maintained into the future (ie like PHP!). It is also completely available as source code, and I keep a buildable copy of the version I am using in my setup at all times.
Of course, even in that kind of setup, so much is outside your control: something I built less than a year ago is already being slowly strangled to death by Microsoft forcing Windows to use Chrome based browsers and yet within it's own apps (eg Office) still only providing IE based browser controls. Thus all the services this little add-on to Office talks to are gradually refusing to work, so I am having to find a way of calling an external browser to do authentication with third parties rather than doing it within the app...
The only thing that remains the same in this industry is the rate of change!
|
|
|
|
|
those are just kids doing home "howto" videos. nobody knows what's in those gazillion npm packages.
everything will be bad until you find yourself a good tutorial. a person who makes sense to you. that is why you'll have to skim over a few tutorials and chose what seems reasonable to you.
i have seen video tutorials where a person goes with a "and now by the magic of copy & paste" from something like console.log("hello world") into a full fledged server that nobody understands how it's working. you blame yourself for not understanding. it is only when you find a person who knows what he is talking about that you realize there are a lot of garbage tutorials out there.
and yes, i am overwhelmed by new technologies. it is not that i care about the 307th web framework that is going to fix the web, because the 306th framework that was proclaimed with fanfare to have fixed the web actually failed.
i am overwhelmed that they make changes to javascript and c++ every year or two and i think it's madness. they are making changes to c# and java and rust and it's madness. the cognitive load is getting bigger and bigger and you end up looking at working code from 15 years ago that is completely different than code from two years ago in the same language.
who cares about vue 4, angular 22, jquery 6 and react 13 when they meddle with the very nature of javascript?
|
|
|
|
|
I know what you mean.
It is all a bit overwhelming.
What I usually do is break it down into smaller pieces.
I would say tackle each part individually:
First, do HTMLThen do CSSThen do general javascriptFollowed by TypescriptThen Vue (or any other framework)Finally, try to add it all together
I found that trying to learn everything combined will get you lost.
Finally, let me wish you all the best learning this 'new' stuff. 
|
|
|
|
|
Vue is a framework, so in spite of all of the yuck of npm package use, that's what a framework requires. I think you need to first make peace with your stack, then look at existing code that your team has generated with it. Take on some small task of updating or adding small functionality to existing code, or just take notes as you learn what the existing code does and how it flows.
This approach is the best way I know to learn a new tech stack. It can be fun if you let it be what it is - a kind of treasure hunt.
Good luck.
|
|
|
|
|
for my personal amusement i would do something else than vue/svelte/angular/whatever, but sometimes we cannot chose. orders are orders.
in that regard, this is a fairly good advice.
although, svelte is tempting. orders notwithstanding.
|
|
|
|
|
In my opinion, the vast majority are neither beneficial nor needed. I agree wit you wholeheartedly.
ed
|
|
|
|
|
I've found W3Schools[^] to be helpful in learning all the bigger technologies.
|
|
|
|
|
|
I'm a desktop developer that is being forced into learning web technologies. I too feel like it's all just too complex for sanity.
I played with the web over a decade ago, so I knew the bare bones. My work recently paid for a Pluralsight subscription. Even then, my issue is finding info for experienced coders that just need to know the gotcha's and syntax of the new language. I don't need a for loop explained to me. I need to know the difference between "==" and "===" in JavaScript.
I did a basic and intermediate JavaScript course by the same person and skimmed through it. Out of the 3 hours of video, I probably found 10 minutes of useful info. None of the sample code worked out of the box, so at least I learned something by fixing it. Then I found Kyle Simpson's Advanced JavaScript, which torn a big one into what I just learned because he actually explained the concepts behind the syntax. He has studied the standard, so he knows JavaScript well. He also has several utilities out there that are not uncommonly used.
The stupid thing is that my work expects me to already know JavaScript (remember, I'm a desktop developer). They want me to learn React and graphQL. I can't even get there until I know the web basics.
On the flip side, there is a junior developer at my job (hired right out of college) that doesn't know what cmd is or how to use it. They can, however, work on websites without issue. It's a different world.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
This seems like an area where there could be a lot of improvement.
I was recently tracking a package by UPS, and it was expedited 2-day shipping.
They shipped out of California, and I'm two states north, in Washington.
They flew the package to Ottawa? If I recall, somewhere in Canada that wasn't BC, for some reason.
From there it wound up in one of the nearest "major" (200k+ people + airport) cities to me.
Then 2 days of nothing from UPS. That's about an hour away from me up the interstate.
I actually contacted them about that, because the only update I got was when they switched the date from "Monday" to "Tuesday" without updating anything else at all.
As a customer who paid extra to get it in 2-days and has a lot out waiting on this package, I was very unhappy with UPS. Enough to contact them.
The tracking actually made the situation worse in terms of how I felt, in this case, because of all of the above.
Some observations:
What made me frustrated was that there was not even any checking in for 2 days. I understand the weekend being what it is, but it went dark yesterday too.
What compounded that frustration was that they inexplicably flew the thing to Canada first, and then they let it sit for 2 days an hour from me without telling me why.
What they could do to improve these applications I think, is
A) Make sure to notify customers at least once a day, and try to give them news. Even if it's just a reason for a delay (inclement weather, or whatever)
B) Attach reasons to things that don't make sense on their face. Why did my package end up in Canada? Why was it sitting for two days?
B might be more difficult, but if the software on UPS employees end had fields for reasons (even dropdowns) any time they had to enter anything into the system, and they had to mark delays with reasons, it could facilitate B. I can think of some ways to do it that probably wouldn't slow down the existing workflow much if at all.
But like, this isn't the first time, or the only shipper that I've found could stand some improvement.
I mean, this actually made me lose some faith in UPS, and I'm sure that's not what they hoped for when they added package tracking features to their site.
Edit: Okay the two days was more like 1 and a half but still.
Real programmers use butterflies
|
|
|
|
|
You'd think they were good at that.
I received my new laptop.
In the morning FedEx said it was in the local warehouse and was "delayed".
5 minutes later, it was dropped at my condo lobby.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
At least in that case they were wrong in your favor. But yeah, could be improved.
Real programmers use butterflies
|
|
|
|
|
I generally get notifications from Amazon that my package "will be delivered today" the day after it is handed to me ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Maybe if you're in Vancouver WA, something went wrong and it got tagged as a Canadian shipment? In which case UPS might do all their customs clearing in Ottawa - though I would have thought Toronto, Montreal or Vancouver BC much more likely. But often tracking packages, I'm sure that that what the tracking software says and reality are different. Particularly when customs is involved, it gets weird, at least in terms of US/Canada shipments. I've seen the tracking location change back and forth across the border several times, when in reality, I suspect it was just moving through a customs office,somewhere.
Keep Calm and Carry On
|
|
|
|
|
Yeah I thought that was weird. I'm really suspicious that I misread it somehow, but I remember doing a double take on it because it was so odd.
Real programmers use butterflies
|
|
|
|
|
USPS aka Snail Mail is no better.
I shipped a couple of books in a package from Cincinnati to suburban Toronto.
The package went to Charleston, West Virginia, then to Chicago and then stayed in Chicago for 3 weeks before going to Toronto!
Another two packages, shipped from Chicago to Fremont, California had a strange history. One was delivered in 5 days and the other went to Spokane and made its way leisurely to Fremont. Both were to go to the same address in Fremont but I guess one package took the scenic route.
Yet another package shipped out of Chicago to San Jose, CA just disappeared. The package could not be tracked with the ID that the USPS had assigned to it. After complaining to the post office in San Jose, they managed to locate the package and delivered it.
We are talking July and October timeframes, not the busy Christmas holiday season.
I swore I would not USPS again except that the alternative of UPS is seemingly no better. 
|
|
|
|
|
I had a similar experience with USPS where a tracking went “dark”. The vendor confirmed and graciously sent a replacement at their expense. About 6 weeks after the original order, the original shipment arrived. It took 2 attempts, but the local post office sent it back to the shipper. They were still out a few dollars for the reship, but they should be able to resell the part.
|
|
|
|
|
I got my recent laptop from amazon about 2 months ago. FedEx was the same way. I think that amazon told me I'd have it in 7 days. FedEx told me I'd have it on two day. It sat in a 'warehouse' for those two days. On day 2 Fedex changed it to day 3, but it was still showing in California. (I'm in Oklahoma.) On day 3 they changed it to day 5. On day 5 it appeared to be sitting in a 'warehouse' in Dallas, and they changed it to day 7. On day 7 it was shown to be in a 'warehouse' in Edmond, about 30 minutes away. And that never changed, but about 2:00 on day 7 it showed up on my doorstep.
I thought, obviously incorrectly, that the packages are scanned at each location and as it is put on the truck. I'm guessing that they miss the scans a lot. They need a CodeProject dev to help them out.
Ron
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
Ron Nicholson wrote: They need a CodeProject dev to help them out.
NEEDZ SCANNIN APP. SEND CODEZ URGENT
(but don't send it via UPS / FedEx / Amazon etc)
|
|
|
|
|
|
honey the codewitch wrote: What they could do to improve these applications I think, is
A) Make sure to notify customers at least once a day, and try to give them news. Even if it's just a reason for a delay (inclement weather, or whatever)
B) Attach reasons to things that don't make sense on their face. Why did my package end up in Canada? Why was it sitting for two days?
Those would be nice but would require a different system from what they currently use. It would require people.
It was sitting there for two days because it was probably waiting for more packages to places near you.
Once I saw a documentary on how major shipping companies work (with actual footage of their systems) and, I am sure there is room for improvement but, their tracking is a lot more complex than someone realizes at first thought.
I will try to describe the process if anyone is interested but be warned, it is long
First: Almost everything is automated with no human intervention. Trucks with packages arrive at the processing centers, humans unload to an unloading conveyor and the packages follow on to a computer guided main conveyor from where they are guided to a "same destination" storage. While on the main conveyor they are also often x-rayed and go through a chemical detector, specially international shipping.
If a package does not have a label visible, the computer sends it on to another conveyor where it is flipped and sent to the beginning of the track (the main conveyor). If the package circulates the system too many times, because the label is too damaged to be read by the computer, it is diverted to an "unreadable label" storage where it will wait for a human to get there and input the data manually and print a new label.
The new label is glued to the package and the is package sent to the beginning of the main conveyor. This is the part where most of the packages get "lost" because the data is input incorrectly. Others get lost because the computer misread the label.
When enough packages are gathered, they are picked up by humans into trucks/planes for the next leg of their journey.
That "same destination" are usually major distribution centers. Lets say you buy something on CityA to be delivered on cityB and those two cities are next to each other with a common border. Your packages will still go to CityC where the distribution center is, even if that center is far away. The reason for this will be clearer later.
The tracking is only updated when a package enters or exits a distribution center because those are the only times when the label is scanned. But it is not immediate to a user because the database they use for their internal tracking is not the same that is used to display information for an user. That information must be mirrored and that takes time due to the size of the database (and is probably on a timer).
Second: Their software must track many millions of packages worldwide with route planning on top. As you might know, route planning is taxing. Finding all solutions for the traveling salesman problem is complex. What they do is use approximations. One of the approximations is to make all packages go through/leave the closest distribution center.
This implies that a "clean" route can be calculated faster by having the same starting/end point, instead of calculating for every pickup and dropout point. The side effect is having stupid routes (from the perspective of whom is following the package tracking).
Another approximation, which is related to the previous, is to use local routing. Each city is divided by areas that have complete "circular" routes in them. This means that there are no paths that go directly in and out, providing trucks with paths that allow them to circle back to another street inside the same area.
This leads to another "stupid route" in which packages in adjacent streets are picked by different trucks and end up in different distribution centers. And, because those areas keep changing depending on where packages are, this might even happen to packages that are picked up from the same place at different times (sometimes minutes apart).
All those decisions they make on how their system works are obviously money driven. They try that those routes, the amount of trucks/planes, and the grouping of packages are minimized so that they can have less employees, less trucks/planes, spend less fuel, etc. This too is computed by their tracking software.
Hope this helps enlighten why some things happen to packages.
That said, I hope no one will let the carriers get away with it when they do not deliver what they promise when they promise. It is our way to force them to improve 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
