|
Gary Stachelski 2021 wrote: If you were to ask people in the 1600's to build the Hoover dam it would be deemed impossible.
The universe is not in fact infinite. There are very real limits. And scaling up known systems is not the same as claiming unknown systems (dams existed long before then.)
Gary Stachelski 2021 wrote: They can be made of earth sized sections that are towed into an acceptable orbit around the sun. So they can be built incrementally over time.
Ignoring the engineering, economical and political points that I already stated.
What are the exact engines would they use? How would they pay for the fuel? Who would pay for the fuel?
Based on your claim then it should be easy for you to find a scaled up version that was built now, which is comparable to that which was only built in the 1600s.
For example the Lake Homs Dam is one mile long and 23 ft high and built in the 1300s. Hoover is 726 ft tall and 1200 ft long.
Thus by your scaling someone should now be building a dam that is 20 times as tall as Hoover. But it just doesn't happen because there are real problems with scaling like that.
Tall buildings are a very good example of that. People would love to build a building that was 1 mile high (or 10,000 meters.) They are even willing to pay for it. But there are real engineering and physical reasons that buildings are not a mile high or even higher. There are also real practical issues with even populating a building even that is much shorter. Then are safety issues such as those from earthquakes and fires.
|
|
|
|
|
jschell wrote: The universe is not in fact infinite. There are very real limits. And scaling up known systems is not the same as claiming unknown systems (dams existed long before then.)
I apologize, I was not clear in my clumsy attempt to make a point. I was not dissing what you had said about the engineering, economic and political climate for large projects. I was not suggesting that scaling up the a dam from an earlier time (even 1300, and the Romans were superb engineers) was equivalent to building a Dyson sphere to harvest the energy of the local sun.
Let me try another equally clumsy attempt to get my point across (please do not take offense).
Today we are in 2024. Lets roll the clock back 1,000 years to 1024. Given the engineering, technological, economic and political climate of 1024. Would it be possible for an engineer to design and construct a cell phone?
My answer would be no. There were huge gaps in knowledge, supporting Infrastructure, etc.
However, in just 1000 years it is now possible for billions of people to communicate using one.
Does this mean we have the knowledge and supporting infrastructure to build a Dyson sphere. Of course not.
However, in another 1000 years (if we don't kill ourselves) we might have some better ideas.
jschell wrote: What are the exact engines would they use? How would they pay for the fuel? Who would pay for the fuel?
I have no clue what technology a civilization that is 10,000 years (or 100,000 years?) more advanced than ours would use to travel around interstellar space or how to fuel it.
No more than a person from 1024 could imagine how to fuel a jet for travel between continents.
(yes, yes I know the argument of the great filter, no technological civilization survives for long since it's technological advancements eventually kill it off. But I am optimistic that maybe an alien one might not fall into that trap).
All I am saying is that it would be hubris to think that as of today, we know everything about how the universe works. We certainly do not know how to build a Dyson sphere. Or if it is even practical to do so.
In any case, Back in 1960 Freedman Dyson wrote a formal paper ("Search for Artificial Stellar Sources of Infra-Red Radiation") on a simple thought experiment which was not aimed at the details of building a Dyson sphere but given one was built, was it possible for us to detect it.
Pretty cool and terrifying if we can detect one that is in the process of getting built.
|
|
|
|
|
Gary Stachelski 2021 wrote: However, in another 1000 years (if we don't kill ourselves) we might have some better ideas.
That is exactly how I read your reply.
We already know enough to posit how to construct large projects. So we can certainly make reasonable assumptions about what large scale project would involve.
And I gave you an example - very tall buildings. With those it is not a matter of will. People want them. People are willing to pay for them. The engineering says it cannot be done.
It can only be done if fantastical technologies somehow come into existence. Technologies that have no current basis.
One thousand years ago there was a basis for larger projects. And they used that to build large projects. So claims of 'what will the future bring' do not provide a basis for that.
Gary Stachelski 2021 wrote: how to fuel a jet for travel between continents.
The first glider was in 1793. The first balloon (with people) was in 1783. The water wheel was invented before recorded history. The first recorded powered engine was in 1 CE. The first wind powered electrical generator was in in 1887.
Gary Stachelski 2021 wrote: All I am saying is that it would be hubris to think that as of today, we know everything about how the universe works
We do however know a great deal about how the universe works at the macro scale. And a Dyson sphere is definitely macro.
|
|
|
|
|
|
Surely if you pointed a telescope at a star with a Dyson sphere then it would not be emitting any detectable radiation. Much like Dark Matter.
Wait... so that is what dark matter is?
|
|
|
|
|
The thought is that no technology is 100%. So if you stick solid objects in front of a star, those objects will heat up. There will be some waste heat radiating from the objects. You can detect that.
In this case, the scientists were trying to be clever in trying to detect not a completed Dyson sphere but one that is still being built. That way they would be able to observe the star, note it's type, and predict the amount of light it should be emitting. If it was emitting less light and had a spike in the mid-infrared range. That might hint that a Dyson sphere was under construction. They also thought of many other conditions that would rule out stars for natural causes for the odd radiation being emitted by the stars. They started with a group of star surveys of stars within 300 parsecs of Earth, which totaled about 5 million stars and whittled it down to 7 stars that were odd and potential candidates. They are trying to get observation time to try and confirm or reject these 7 stars.
|
|
|
|
|
|
Startups will claim anything...
Hogan
|
|
|
|
|
When I see any article where a startup is making tall claims my mind goes straight to Theranos, FTX, Nikola and such.
|
|
|
|
|
The problem and solution reminds me of analog computing but using light instead of electricity.
Interesting that both quantum and this light method both look for minimal energy states to define the best possible solution to the problem.
|
|
|
|
|
I've come to understand quantum computing to be a bit like Plinko on the Price is Right.
You set up your equation which can metaphorically be represented as placing the pegs into the board and then setting all the dividers for the troughs the chip may eventually fall into.
As a chip dropped in plinko settles to the lowest entropy of a trough. "Execute" is dropping a bunch of chips into the board and letting them settle entropically, then your answer is in counting the troughs.
There are some ways this metaphor doesn't play but some ways it plays really well.
|
|
|
|
|
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”.
There should be a similar saying in regards to writing (non unit) test cases.
"Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software"
I'm going through some test cases on a large software and the tests cases are just a description of what I need to do.
In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work.
Seriously, do you know of any good white paper on how to write good test cases ?
groan.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Maximilien wrote: John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. This... this right here... is gold.
Maximilien wrote: In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Sounds like someone who wrote those tests didn't know squat about writing tests (which is a lot of people). A unit test should never connect to a live resource. Not only is that non-deterministic, but you can't run 1,000s of tests quickly that way.
Maximilien wrote: Seriously, do you know of any good white paper on how to write good test cases ? Wish I could help with that buddy. For me, it was a combo of coworkers helping and trial and error with Stack Overflow Googling.
Jeremy Falcon
|
|
|
|
|
we're not running unit tests; I don't know how I could integrate that in our ancient/antiquated codebase
We're doing functional and integration testing and acceptance testing.
It's just hard to change the inertia; that's why I would need some good resources to help me suggest some changes.
Thanks for the moral support.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Ooops. Totally missed the non-unit part.
If these are integration "test cases" they sound more like documentation for manual steps than anything else then. Probably could've achieved the same thing in a README.
Jeremy Falcon
|
|
|
|
|
Would test automation help?
Had used Selenium framework, for a web application, some years ago, and our test scripts automated all the steps. There must be a similar framework for desktop apps.
|
|
|
|
|
My Sr. partner is the best when it comes to breaking things:
0: Entering non-numeric chars where numbers should go or invalid numbers such as 1,1.2 or 1.1,2 (fun fact, letters up to f will happily identify as numeric)
1: Extremely long text/numbers, special characters, 0s as divisors
2: Leaving 'required' fields blank
3: Using the back button in web apps
Of course, there are some situations you can't predict. That's what users are for!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
and/or
- cancel dialogs
- close app (with click on "X") while db is in edit mode
- kill app with task manager while someone is editing something
- use special - non ascii - chars where it is not expected
- simulate high load with endless read/write operations
- change screen size/resolution to unusual values
modified 14-May-24 15:45pm.
|
|
|
|
|
It comes down to my biggest beef with tests and that's being only as good, generally, as whoever wrote what they're testing.
For one, some jabroni didn't really write tests for your system. They wrote some documentation.
If you can't run them in an automated fashion - without manually hunting records down and manipulating data? Then they simply aren't tests and if the person's task was to write tests, they 100% failed that task.
You write the test so that it stages the data you know will work and then delete that data post-test.
[OneTimeSetup] / [OneTimeTearDown] are the decorators for NUnit to do stuff like that.
When we started writing a bunch of tests, we settled structuring things linearly like the following with regions for:
Class Members
Assemble/Setup
Act/Invoke
Test Asserts
Cleanup
|
|
|
|
|
Get some experienced testers to bash it hard - much better than test scripts IMHO - writing(and testing / maintaining test scripts) is often harder than coding the application
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
|
|
|
|
|
For at least 30 years, we have had/practiced the "5-year-old robustness test":
Put the kid in front of a keyboard and a screen, and tell him: Do anything you want. If you make it lock up, and can show daddy/mommy what you did, you'll have an ice cream cone!"
I know of a few ice cream cones awarded that way
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I like it.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Brilliant! I need to offer more ice cream cones to my QA team.
Religious freedom is the freedom to say that one plus one plus one does not always make three.
Scientific freedom is the freedom to say that parallel lines in a non-euclidean reference system may shake hands.
|
|
|
|
|
Maximilien wrote: In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Why not edit a single record so it will work?
I'm currently doing a project where we're rewriting an old VB6 application that used to use a dBase database.
It's SQL Server now, but everything is not what you'd expect (everything is char(x), even bools, which have "Y" or "" (and sometimes "N"), except some ints, which are int or decimal(x,y)).
Lots of magical numbers and strings too.
Some fields even are like "X X " in which the first X means "option 1 should be used" (whatever option 1 is), the empty second and third position means those options are off and the fourth X means option 4 should also be used (the software only uses four options, even though it's a char(10), also it's not always X, sometimes and option can be, for example, "S" for small or "L" for large, etc.).
Anyway, finding a row you can use and writing a WHERE clause is a pain, so I just edit the top row so it'll fit my test/use case.
|
|
|
|
|
1) Mind internationalization. Is your app translated? In how many languages? Serious work to do if this number is greater then 10.
2) How does the GUI looks like on a native Chinese (Traditional or Simplified)/Japanese/Korean PC?
3) Input long texts in various languages, with many specific characters. Special care when comparing and processing texts - in which culture?
4) Did you specify a culture when installing the app DB? If not, the SQL server default one will be used. Try different cultures/collations etc.
5) Input/use numbers in various cultures, alternating decimal/thousand separators etc.
6) Input/use datetimes in various cultures.
7) Set the date of the PC to 29th february in a leap year and test app functionality.
8) If you read text from disk/stream, create test files containing binary data (e.g. 0x1A/EOF - can your app read text beyond that byte?). Or create test files that have \r\n or only \n as end of line etc.
|
|
|
|