|
Nope, iPAQ PDAs: The New CodeProject Web Farm[^]
"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!
|
|
|
|
|
I can't believe that no one has answered correctly yet.
It is in honor of Chris' mother, a hamster.
|
|
|
|
|
Although his father was quite lucky to find Sambucus[^] in the southern hemisphere. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Because if he had called them Guinea Pigs they might have started to refuse the injections!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Damn - looks like we need to change the hamsters in the cage.
cheers,
Chris Maunder
That's the earliest reference I can find.
Followed by this[^] in March 2003.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Are we just delayed due to holiday hangovers? Am I being too impatient? It seems like it has been awhile since the last one.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Software development isn't a contest.
|
|
|
|
|
Uh oh. Someone has clearly hacked my profile and put all these fake contest wins in it.
honey the codewitch - Professional Profile[^]
Who do I talk to about that?
PS: I didn't say software development was a contest. You strongly implied I said that. There's a rather large difference between those two things.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: PS: I didn't say software development was a contest. You strongly implied I said that
Yeah, but this is the Internet. We're not supposed to read the posts we reply to.
Jeremy Falcon
|
|
|
|
|
|
|
Chris going on holiday? We can't have that! 
To err is human. Fortune favors the monsters.
|
|
|
|
|
If you mean the monthly competition, I didn't think it was fair to articles submitted late December for the contest to start Jan 2.
Thanks,
Sean Ewington
CodeProject
|
|
|
|
|
Microsoft is pushing on us this system as an alternative (instead of .net core and Blazor) of rewriting some big old order and data processing applications. Anybody with any experience on this? At first glance I'm genuinely scared.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Yet another no code attempt. Of course Microsoft has to jump on the bandwagon. Nothing to get scared about. 
|
|
|
|
|
And I doubt they'll eat this dog food.
|
|
|
|
|
Thanks. What I'm scared of is that we will put a lot of effort in this conversion and at the end it will become clear that there are "too many exceptions" and the project will be scraped. Or the end result will be unusable mess.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
I would never look at a no/low code solution for a project - you will inevitably encounter something that the no/low code can't do.
|
|
|
|
|
At the end of the day the thing low code cannot do is "be a developer" I think.
What happens in low code if you make, with its help, an error of intent instead of function?
That is, "it worked as designed" but the design was wrong?
When you have developers, you say "Oh, you guys got the design wrong. We meant <x>." (Kidding, mostly)
You (as a developer) go do data-doctoring and maybe take care of some other adhoc processes that need to spin off and happen as a result of the issue.
In low code? Do you just start pursuing creating those tasks in low code? How do you even know the need exists?
|
|
|
|
|
Do a head to head eval based on Gartner magic quadrant for low code. There are at least three products I would recommend ahead of MS power apps.
My memories of power apps demos/POCs:
Trying to write a simple formula to enable/disable a button based on a few other fields was barely writable and unintelligible.
Good luck writing the logic to prevent users from double clicking a button and submitting the form twice!
|
|
|
|
|
I read here somewhere recently that Google is pushing to make Risc V de riguer for Android phones.
In addition Espressif has IoT MCUs based on Risc V processors, and appears to be moving to Risc V for their new projects.
This tells me Risc V is suitable for CPUs with a wide range of capabilities.
It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry.
I'm really interested in this technology, and although I'm not a fan of Espressif's current Risc V offerings, which are low power, but kind of anemic, they have a soon to be released offering
The ESP32P4
Triple core (2x400MHz, 1xULP40MHz), 768kB of SRAM, 50 GPIO, wireless connectivity for days, all Risc V based.
And if Android primarily adopts it, how long before Windows follows suit?
To err is human. Fortune favors the monsters.
|
|
|
|
|
Microsoft is too embedded in the x86/64 architecture. This was one of the problems with the AlphaServer versions of Windows NT - emulation was far too slow.
|
|
|
|
|
Doesn't dotNet change that?
In dotNet, there is no emulation; each assembly is JIT compiled to native code. I believe that even available instruction set extensions are considered, to avoid runtime testing - all JIT compilation is done on the target machine (but don't quote me as a source on that). (This is obviously when the code is distributed as dotNet assemblies; you can generate a complete, statically linked executable file for distribution; then the code must test for instruction set extensions at run time!)
I also believe that the structure of the Windows kernel has been significantly changed since the NT days, in the direction of a much more well defined hardware abstraction layer that handles different architectures, leaving the higher layers unaffected. With a HAL definition, they are not talking about any sort of emulation, but true native code - think of the HAL as the code generation part of compilation! (If you like: The JIT part of dotNet compilation.) Historically, Windows has been running on i860, Alpha, Itanium, MIPS, PowerPC, ARM, ARM64, IA-32 and x86-64 - that provides quite a background for defining a HAL suitable for a multitude of CPU architectures (including Risc V).
Another problem with the Alpha was that the processor itself flopped. It made a good cooking plate for frying your lunch meal, though. I have been working with the Alpha for just a couple years: We bought it to teach the tech. college students Unix, so it was running DECs own Ultrix. I can assure you: Performance problems was not limited to Window NT! The vendor doubled the amount of RAM installed, at no cost to the college, in an attempt to make it perform as promised in the contract, but even after that, it didn't "run" - at most, it walked, dragging its feet along the ground.
My impression is that DEC had problems with context switching performance when working in a small format. Running a single process could show impressive results, but switching among 20 user front ends (running X11 servers) didn't work out. It reminded me of the early VAX days: The company of a friend of mine bought a VAX 730, and benchmarked process switches to take 100 ms - one tenth of a second! They had to rewrite their DBMS from three to two main processes, so that fewer process switches was needed, to get acceptable performance.
|
|
|
|
|
honey the codewitch wrote: It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry.
Keep dreaming! It has happened! Look at the x86 desktop architecture. Many years earlier, it was the IBM 360 architecture. For smartphones, the ARM architecture has been a de facto standard CPU architecture for quite a few years.
The problem is that lots of developers discover that there is something new, which makes them reject the estabished, accepted, respected and honored standards - they want to throw them out. Look at yourself: What makes you think that ARM is not "a CPU architecture that could be leveraged across the tech industry"? You have found that RISC V has some advantages that makes it a better alternative. If we switch horses from ARM to RISC V, it won't take long before someone come up with yet another architecture that has advantages over the RISC V.
Over the years, I have lost all kinds of trust in "Strangler jeans: One size fits all!" You must be prepared to handle alternate solutions. Monoculture is never good. (My t-shirt that states "Stereotypes are real time savers" is sort of true, but obviously ironic.)
So make yourself a hardware abstraction layer, and implement that on all the different CPUs that you come to work on.
(Regarding RISC V: I 'discovered' it in my last job. The company makes IoT chips externally looking as two core ARM chips. Under the cover, there are several other cores, managing various parts of the hardware asynchronously with the two main ARM chips. One of these 'secret' cores is a RISC V.)
|
|
|
|
|
https://www.digikey.com/en/resources/risc-v[^]
"At the heart of the differences between ARM and RISC-V is the matter of closed and open-source hardware. ARM is closed source whereas RISC-V is open source."
Big delta
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
