Could be. It's probably intended to say forms of speculative, philosophical, political, and/or editorial commentary. In other words, "Describe your products, sanctioned facts/news, and then shut up."
They stated a reason, but it was a dumb one in my opinion because it had multiple work-arounds that were far less problematic than breaking the API interfaces.
Perhaps it's a side issue, but I'm ticked that Php dicked around and changed their "official" API calls to sqlite. That makes me not trust usage of sqlite as much. It also has odd error handling (or non-handling in some cases) that's poorly documented. The reasoning behind their choices seems to be very off or ad-hoc.
Databases are a nice tool for managing bunches of attributes. If you are doing something trivial, maybe they're overkill, but if you have lots of data and relationships, they are often the best tool for the job.
The alternatives are usually uglier.
For example, sometimes I wish involved GUI's were managed in databases, because managing bunches of GUI attributes in source code grows into a nightmare. You'll want to search, sort, study, change, and group GUI info by different aspects at different times. Doing this with bunches of source code can be a PITA.
(However, GUI's would be better served with "dynamic relational" (DR) instead of "static relational" in my opinion. I'm waiting for somebody to implement DR.)
It needs examples. I enjoy seeing new ways to express or encode ideas, but I'm not sure what problem the author is trying to solve or has seen solved in various languages or API's.
The server would do it ONE WAY for all client brands and versions (unless explicitly coded for differences).
Let me re-state this to make sure I'm clear. By "one way" I don't mean the same layout for all client devices, but rather that the layout would be consistent across all client devices for a given target size.
For example, if we use centimeters as our standard (as an example only), then if an Apple client had a 8cm by 20cm screen and if an Android client had an 8cm by 20cm screen, then the positions and proportions of the GUI objects would be identical. This is different than the current situation where the same screen size on a given device or browser may have variations not found on another browser or device with the same screen size. Buttons or text may wrap differently, for example.
Server-side scaling and layout management would eliminate this problem, and simplify the client software because the client software no longer needs auto-flow logic in it. The client will NOT control/determine wrapping, for example. It just "dumbly" plots vectors linearly based on the specified scale.
Note that similar traits are one reason PDF lives on. HTML is too finicky and inconsistent with regard to client-side renderers. PDF's look almost identical on all client-side devices (with a few exceptions), at least proportion-wise. You don't get different wrapping breaks on different clients.
Something tells me Steve would have eventually been at least mildly successful in something even if he never met Woz etc. He was highly driven. Pixar owes some of its success to Jobs, even though it's only remotely related to end-user computers. He sensed an emerging market there.
His (non-genetic) father was interested in cars and cabinetry and tried to get Steve interested in those also. But, he was drawn to electronic gizmos instead. (It's true, though, his father got him interested in the "look and feel" aspect of things, and that played a part in Apple's higher-end market target.)
Regardless, the chance of a Steve clone being successful is still likely greater than a random person. It's like picking stocks: no guarantees, but at least maximize your chances. Cloning successful traits increases your chances. I never claimed it a sure shot.
There will probably be countries that allow tinkering to create smarter and/or more disciplined children. If the USA doesn't allow it, we may fall behind and not be competitive with such countries.
Also, there may not be enough "room at the top". If you cloned Steve Jobs 1,000 times, that doesn't mean there would be 1,000 Apple Co's. It mostly just means more competition for the "elite" jobs. There's plenty of interesting ideas floating around (I have some of my own I think are good) but the market-place can only test and tune so many at a time.
They were looking for a longer-term average, not specific short-term disturbances/changes. Maybe if their instruments were sensitive enough, they may have inadvertently spotted such waves, but that's not what they set out to find any more than Voyager was designed to find active Io volcanoes. (Galileo probe may have missed Europa's now-known plumes because mission planners didn't know to look.) It's often the case that you set out looking for X, but find Y instead.
Whether the existence of waves implies "ether" or not is probably a tricky definition issue. If they didn't pre-define ether clearly enough, then arguments could perhaps be made both ways. It was a general notion at the time rather than a precisely defined phenomenon. It's hard to precisely define a phenomenon until AFTER you discover and study it.
Okay, that makes sense. But I imagine that some still made some very approximate calculations, and wonder if these early attempts were either very wrong, or if they simply felt that they were too imperfect to conclude that the course GW detection instruments of the day too course still to have a decent chance. Was there ever a sense that the early GW detectors were unlikely to catch anything (barring some completely unknown object type being discovered/detected)?
For one, you don't get different clients doing auto-flow different ways. The server would do it ONE WAY for all client brands and versions (unless explicitly coded for differences).
Clients doing auto-flow different has been a huge practical problem in my experience. Sure, with enough experience and practice one might finally over-come that, but why make it Rocket Science when it could be dirt simple: move it to where you want? I'm a multi-hatter in my position, I don't have the time to master auto-flow nuances, and why should an org pay for that when it COULD BE simple. Why pay 3x for something that gives a 10% benefit (at best). It's not logical.
In-house staff had no problem with coordinate-based tools like Oracle Forms and VB classic. The auto-flow crap has confused a good many.
Second, you don't have to use auto-flow at all, or only use it for parts of a project instead of the entire thing (like the grid example I gave). The current standards don't give you a practical coordinate-only option, in part because font rendering is too unpredictable.
It would be easier for such sites to require a special meta-tag or other "marker", and push to make it easier for parents to indicate a user account is a minor's account.
Those selling devices would be required to either make setting such account info easier, or provide easy-to-find instructions. (Current such options tend to bury it under layers of obscure config menus.)
You still have to deal with out-of-country sites, but that's going to be a problem either way.
In a hospital, Doctors are stars and everything else is a cost center. One exec after another will show up and squeeze those costs further and further.
Cutting IT budget gives them an almost certain way to look good. The risk of getting the main systems hacked is roughly 1 in 50. It generally goes against human nature to give up a certain chance of looking good in exchange for preventing a 1 in 50 really "bad" event that doesn't outright kill you.
Don't complain about human nature; rather find a way to work with human nature as is. Mandatory security audits may be the only practical way, but it will jack up medical costs for patience.
So you're saying the designer is going to create a static composition for every permutation?
I didn't say that. I don't know where you got that. Let me try again: The resizing is computed ON THE SERVER, NOT THE CLIENT. But, it still happens.
The phone example was just an optimization suggestion. And again, I'm mostly thinking about work-oriented applications for desktops. Users don't normally resize their screen very often.
Note you could also have a zoom-mode in your browser that could scale up and down linearly, similar to Control plus and minus in web browsers, but it would be more exact proportion-wise.
Yes, web design gets progressively harder year by year, but WYSIWYG editing is the biggest cause of trouble. This is why I typically handcode HTML, because you really have to build it structurally, rather than visually for it to adapt properly.
If you target a screen-size of what's typically about 1000x by 700y by current conventions, you cover what's usually needed for work. The exception may be a scrollable grid, I see no problem with allowing the grid window/panel to stretch. But most panels can work just fine with WYSIWYG layouts. Tool panels and data-entry forms can be designed WYSIWYG.
Client-side auto-adapting is "nice", but not worth the added cost. I used to spend about 70% on business logic and 30% and UI. With the web stack it's now more like 80% on UI and 20% on biz logic. That's messed up.
Economies could save possibly trillions if they bring back WYSIWYG. It made developing of work-oriented software cheaper, quicker, and simpler. Chasing auto-flex, especially on the client-side, has been labor sink. It has its place, but that place is NOT everywhere.
Indeed. Co's that rely heavily on outsourced labor are generally dysfunctional in my experience. But they survive by being cheap. If you are constantly reworking your own foul-ups, then you might as well rework the foul-ups cheaply.
Think of Comcast: they don't care about quality and don't seem to mind sucking (being an oligopoly with thin competition). But if they can suck cheap enough, they make a profit.
It's kind of comparable to throw-away consumerism: you don't repair anything, you just toss it out and buy a new one because the cost of buying a new one is on par with repair. But it feels quite wasteful. You know something is out of balance, but live with it because you are powerless to change it.
I believe it's mostly caused by the fact that any job that is remote-able is also off-shore-able. What remains are jobs that involve lots of collaboration, where hand and facial gestures make a competitive difference.
Being in the "right" city also means you can poach needed talent from competitors. It's the network effect: You need enough talent to be the "right" city, but the talent only goes to the right city, creating a catch-22 that makes it hard for other cities to catch up.
But for the most part, "raw" production will increasingly come from machines and 3rd-world labor. I see more openings for administrative and process coordinators than for those who do "heads-down" creation of product or code. You need domain experience, people/communication skills, and a memory for lots of details flying in from different directions. The problem is that not everybody is cut out for that.
Slashdot Mirror
Yoda points of mod, you get!
nuf sed
Could be. It's probably intended to say forms of speculative, philosophical, political, and/or editorial commentary. In other words, "Describe your products, sanctioned facts/news, and then shut up."
I appreciate their directness. Usually such rulers call it "subversive" material. This time they call it "thoughtful" material.
I don't know whether that's a step up on the maturity ladder, or a new brand of bureaucratic silliness.
They stated a reason, but it was a dumb one in my opinion because it had multiple work-arounds that were far less problematic than breaking the API interfaces.
They fed the trolls.
Perhaps it's a side issue, but I'm ticked that Php dicked around and changed their "official" API calls to sqlite. That makes me not trust usage of sqlite as much. It also has odd error handling (or non-handling in some cases) that's poorly documented. The reasoning behind their choices seems to be very off or ad-hoc.
Blame it on Bush family, accuse Tim Cook of not having a birth cert, and make ISIS pay for decrypt.
No, this guy knows better. "72experiencedSluts"
Why not? We spend jillions for a lame fighter jet. What's a big server farm in comparison?
Databases are a nice tool for managing bunches of attributes. If you are doing something trivial, maybe they're overkill, but if you have lots of data and relationships, they are often the best tool for the job.
The alternatives are usually uglier.
For example, sometimes I wish involved GUI's were managed in databases, because managing bunches of GUI attributes in source code grows into a nightmare. You'll want to search, sort, study, change, and group GUI info by different aspects at different times. Doing this with bunches of source code can be a PITA.
(However, GUI's would be better served with "dynamic relational" (DR) instead of "static relational" in my opinion. I'm waiting for somebody to implement DR.)
It needs examples. I enjoy seeing new ways to express or encode ideas, but I'm not sure what problem the author is trying to solve or has seen solved in various languages or API's.
too late. Comcast & Trump unleashed.
Let me re-state this to make sure I'm clear. By "one way" I don't mean the same layout for all client devices, but rather that the layout would be consistent across all client devices for a given target size.
For example, if we use centimeters as our standard (as an example only), then if an Apple client had a 8cm by 20cm screen and if an Android client had an 8cm by 20cm screen, then the positions and proportions of the GUI objects would be identical. This is different than the current situation where the same screen size on a given device or browser may have variations not found on another browser or device with the same screen size. Buttons or text may wrap differently, for example.
Server-side scaling and layout management would eliminate this problem, and simplify the client software because the client software no longer needs auto-flow logic in it. The client will NOT control/determine wrapping, for example. It just "dumbly" plots vectors linearly based on the specified scale.
Note that similar traits are one reason PDF lives on. HTML is too finicky and inconsistent with regard to client-side renderers. PDF's look almost identical on all client-side devices (with a few exceptions), at least proportion-wise. You don't get different wrapping breaks on different clients.
Something tells me Steve would have eventually been at least mildly successful in something even if he never met Woz etc. He was highly driven. Pixar owes some of its success to Jobs, even though it's only remotely related to end-user computers. He sensed an emerging market there.
His (non-genetic) father was interested in cars and cabinetry and tried to get Steve interested in those also. But, he was drawn to electronic gizmos instead. (It's true, though, his father got him interested in the "look and feel" aspect of things, and that played a part in Apple's higher-end market target.)
Regardless, the chance of a Steve clone being successful is still likely greater than a random person. It's like picking stocks: no guarantees, but at least maximize your chances. Cloning successful traits increases your chances. I never claimed it a sure shot.
There will probably be countries that allow tinkering to create smarter and/or more disciplined children. If the USA doesn't allow it, we may fall behind and not be competitive with such countries.
Also, there may not be enough "room at the top". If you cloned Steve Jobs 1,000 times, that doesn't mean there would be 1,000 Apple Co's. It mostly just means more competition for the "elite" jobs. There's plenty of interesting ideas floating around (I have some of my own I think are good) but the market-place can only test and tune so many at a time.
They were looking for a longer-term average, not specific short-term disturbances/changes. Maybe if their instruments were sensitive enough, they may have inadvertently spotted such waves, but that's not what they set out to find any more than Voyager was designed to find active Io volcanoes. (Galileo probe may have missed Europa's now-known plumes because mission planners didn't know to look.) It's often the case that you set out looking for X, but find Y instead.
Whether the existence of waves implies "ether" or not is probably a tricky definition issue. If they didn't pre-define ether clearly enough, then arguments could perhaps be made both ways. It was a general notion at the time rather than a precisely defined phenomenon. It's hard to precisely define a phenomenon until AFTER you discover and study it.
Okay, that makes sense. But I imagine that some still made some very approximate calculations, and wonder if these early attempts were either very wrong, or if they simply felt that they were too imperfect to conclude that the course GW detection instruments of the day too course still to have a decent chance. Was there ever a sense that the early GW detectors were unlikely to catch anything (barring some completely unknown object type being discovered/detected)?
It's like Alzheimers: you don't have to buy a new magazine because you can just read the same one over every day.
For one, you don't get different clients doing auto-flow different ways. The server would do it ONE WAY for all client brands and versions (unless explicitly coded for differences).
Clients doing auto-flow different has been a huge practical problem in my experience. Sure, with enough experience and practice one might finally over-come that, but why make it Rocket Science when it could be dirt simple: move it to where you want? I'm a multi-hatter in my position, I don't have the time to master auto-flow nuances, and why should an org pay for that when it COULD BE simple. Why pay 3x for something that gives a 10% benefit (at best). It's not logical.
In-house staff had no problem with coordinate-based tools like Oracle Forms and VB classic. The auto-flow crap has confused a good many.
Second, you don't have to use auto-flow at all, or only use it for parts of a project instead of the entire thing (like the grid example I gave). The current standards don't give you a practical coordinate-only option, in part because font rendering is too unpredictable.
It would be easier for such sites to require a special meta-tag or other "marker", and push to make it easier for parents to indicate a user account is a minor's account.
Those selling devices would be required to either make setting such account info easier, or provide easy-to-find instructions. (Current such options tend to bury it under layers of obscure config menus.)
You still have to deal with out-of-country sites, but that's going to be a problem either way.
Cutting IT budget gives them an almost certain way to look good. The risk of getting the main systems hacked is roughly 1 in 50. It generally goes against human nature to give up a certain chance of looking good in exchange for preventing a 1 in 50 really "bad" event that doesn't outright kill you.
Don't complain about human nature; rather find a way to work with human nature as is. Mandatory security audits may be the only practical way, but it will jack up medical costs for patience.
I didn't say that. I don't know where you got that. Let me try again: The resizing is computed ON THE SERVER, NOT THE CLIENT. But, it still happens.
The phone example was just an optimization suggestion. And again, I'm mostly thinking about work-oriented applications for desktops. Users don't normally resize their screen very often.
Note you could also have a zoom-mode in your browser that could scale up and down linearly, similar to Control plus and minus in web browsers, but it would be more exact proportion-wise.
If you target a screen-size of what's typically about 1000x by 700y by current conventions, you cover what's usually needed for work. The exception may be a scrollable grid, I see no problem with allowing the grid window/panel to stretch. But most panels can work just fine with WYSIWYG layouts. Tool panels and data-entry forms can be designed WYSIWYG.
Client-side auto-adapting is "nice", but not worth the added cost. I used to spend about 70% on business logic and 30% and UI. With the web stack it's now more like 80% on UI and 20% on biz logic. That's messed up.
Economies could save possibly trillions if they bring back WYSIWYG. It made developing of work-oriented software cheaper, quicker, and simpler. Chasing auto-flex, especially on the client-side, has been labor sink. It has its place, but that place is NOT everywhere.
Indeed. Co's that rely heavily on outsourced labor are generally dysfunctional in my experience. But they survive by being cheap. If you are constantly reworking your own foul-ups, then you might as well rework the foul-ups cheaply.
Think of Comcast: they don't care about quality and don't seem to mind sucking (being an oligopoly with thin competition). But if they can suck cheap enough, they make a profit.
It's kind of comparable to throw-away consumerism: you don't repair anything, you just toss it out and buy a new one because the cost of buying a new one is on par with repair. But it feels quite wasteful. You know something is out of balance, but live with it because you are powerless to change it.
I believe it's mostly caused by the fact that any job that is remote-able is also off-shore-able. What remains are jobs that involve lots of collaboration, where hand and facial gestures make a competitive difference.
Being in the "right" city also means you can poach needed talent from competitors. It's the network effect: You need enough talent to be the "right" city, but the talent only goes to the right city, creating a catch-22 that makes it hard for other cities to catch up.
But for the most part, "raw" production will increasingly come from machines and 3rd-world labor. I see more openings for administrative and process coordinators than for those who do "heads-down" creation of product or code. You need domain experience, people/communication skills, and a memory for lots of details flying in from different directions. The problem is that not everybody is cut out for that.