|
Microsoft has created a proof of concept for storing data on glass. Because nothing says, "forever storage" like the stuff that breaks when your cat pushes it off the counter
|
|
|
|
|
I tried hiding some data from my wife on glass, but she saw right through that. If its Superman shouldn't they be storing it on lead or kryptonite or something?
|
|
|
|
|
Did they forget that you could also store it on a DVD or a hard disk....
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Available beginning at Microsoft’s Ignite conference as a public preview, Visual Studio Online provides managed, on-demand development environments that can be used for long-term projects, to quickly prototype a new feature, or for short-term tasks like reviewing pull requests. Your code is in The Cloud(tm), so I guess you need an IDE there too?
“ Moving your development workload to the cloud boosts your overall computing power so your personal machine can edit media assets, email, chat, stream music, or do anything else, more.”
It can’t now?
|
|
|
|
|
I thought it’d be fun to tell you about the history of the GC configs ‘cause it’s almost the weekend and I want to contribute to your fun weekend reading. Because one person's garbage is another's data to conserve?
|
|
|
|
|
It is interesting and educational to go back in time and look at how programmers were represented in popular culture. What did they think of us? Did they know who were? "I’ll create a GUI interface using Visual Basic, see if I can track an IP address"
|
|
|
|
|
My sister once asked me if when the world falls to anarchy, and we're beaten down by our robot overlords, could she come to me and have me fix it.
I told her we're all doomed, because my first response would be to suggest rebooting the overlords, or look for the on/off switch.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 4-Nov-19 6:46am.
|
|
|
|
|
The chemistry behind SmartGlass was first discovered when a 19th-century scientist gave quinine to his dog and experimented on the resulting urine. "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!', but 'That's funny ...'"
OK, mostly posted so that I could say I've used Car & Driver magazine and the Wall Street Journal on the same day. But also because - as Chris pointed out - you needed to know what happens if you give your dog a gin and tonic and then stick electrodes in its pee.
|
|
|
|
|
The first public release of our C++/CLI support for .NET Core 3.1 is now available for public preview! Because I know people have been waiting for cross-platform C++
|
|
|
|
|
Move toward ‘digital sovereignty’ will restrict data services along national borders in a global economy, Amazon and Microsoft say. It's like the other clouds, but it requires standardization on droplet sizes and fluffiness
And it always rains on Britain? Work with me here.
|
|
|
|
|
Quote: “removes many of the fundamental benefits of cloud computing for customers—it restricts freedom of choice, flexibility, and ability to scale globally
use case:
I make website which 99.9999% of my users are Germany based, because its an internal application with cloud hosted functionality. I do not need GLOBAL scale-ability. If I do, I will make that a requirement of any solution I seek.
Data is a product. It should be treated like any other product in country of use.
I am pro freedom of network access, but also sane enough to respect some, not all, government entities requests for managing data in their domains.
|
|
|
|
|
maze3 wrote: I am pro freedom of network access, but also sane enough to respect some, not all, government entities requests for managing data in their domains.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
It's November 2019 and Los Angeles is in a state of urban decay. The population has dwindled, and humans face a new threat from manufactured biological robots gone rogue... "I've seen things you people wouldn't believe."
|
|
|
|
|
The work can have significant applications in cognitive disorder treatment and post-stroke rehabilitation. 'Oh, so you're thinking of turning me off?'
|
|
|
|
|
The Hack_Right program aiming to help young hackers avoid cybercrime and use their skills for good has received a pledge of support from about 20 companies. "There is no right or wrong, just fun and boring."
|
|
|
|
|
Microsoft’s focus as a company is on productivity, but a recent experiment by Microsoft Japan suggests with a 4-day workweek we may be more productive if we work less. Me too
If I'm 40% more productive with a 3-day weekend, imagine how productive I'd be with a 6-day weekend!
|
|
|
|
|
With regards to software development, productivity is an entirely subjective concept.
It's entertaining and somewhat disheartening to read some of the definitions of productivity:
Quote: the state or quality of producing something, especially crops.
okaaaay.
Quote: the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.
Unit tests anyone?
And my favorite:
Quote: the rate of production of new biomass by an individual, population, or community; the fertility or capacity of a given habitat or area.
Wikipedia has an interesting definition:
Quote: Productivity describes various measures of the efficiency of production. Often, a productivity measure is expressed as the ratio of an aggregate output to a single input or an aggregate input used in a production process, i.e. output per unit of input, typically over a specific period of time.
The thing is, the concept of "input" and "output" with regards to productivity is highly abstract when it comes to defining productivity for software development. Input can range from someone saying "this needs to be done" to a full blown spec. Output can be anything from a bug fix to an entire application.
Because of this wildly ludicrous range, we have scrum and agile methodologies which create sprints, breaking down "productivity" into more chewable (but not necessarily more digestible) units:
Quote: A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.
And it accomplishes this by forcing an arbitrary time interval to the work from which, again somewhat ludicrously, the team's "velocity" can be measured to create nice graphs for the venture capitalists that are keeping the sinking ship from, well, sinking.
And because only so much can be done within a fixed time period, we have "iterations" and "refactoring" and "only do the minimal amount necessary to get the task in the sprint done." So velocity looks good on paper, but does anyone measure how many times the same piece of code (and its dependencies) get refactored over a thousand or ten thousand sprints because the task wasn't given enough time to do it right in the first place?
Of course the solution to that is to decompose the task into, you guessed it, smaller tasks which are "sprintable." Rinse and repeat until you get a tower of babbling developers, project managers, and C-level managers, each speaking in unrecognizable tongues to the others.
Outsourcing addresses this bottomless pit by getting rid of costly developers and hiring droves of cheap developers that have laser focused myopic vision (see post below on the 737 Max) which results, if you're lucky, in a failed product, and if you're less lucky, death. Of the project, of people, of the company, of the management, any and all of the above.
So how do we then measure developer productivity? Let me ask a different question. Why should we measure developer productivity?
The productivity of developers is meaningless before the product hits the market. How can you measure "input" and "output" when the damn thing isn't even generating any money? Charts of velocity are useless, at best they might tell you when your money is going to run out or when the VC's are going to pull the plug. I feel my argument is weak here, but I stand by the premise.
The productivity of developers after the product hits the market and is generating revenue might be measurable against certain criteria, such as sales and customer satisfaction. It is also easier to perform sprints on an existing product that is in its maintenance cycle rather than its development cycle because maintenance is mostly tooling improvements, bug fixes and specific new features and the eternal pendulum swing between fragmented (microservices, serverless, etc) and monolithic architectures.
Using sales as a criteria becomes useless when you have a monopoly, or more PC, "cornered the market." Or you have enough money to buy your competition. Customer satisfaction? Who really cares as long as you're making sales?
So how then do we measure productivity? Simple. How much money did I make today vs. how much did my developers cost today? If that ratio is > 1, someone (not necessarily your developers) is productive. It could even be the consumer, being productive enough in whatever they do to afford your product, be they person, collective, corporation, or government. If that ratio is < 1, then you have a productivity problem. Somewhere. Not necessarily your developers. Maybe the consumer isn't buying enough of your product due to an economic downturn. Or simply that your product sucks.
The only time you can actually measure developer productivity is when the company is too small to have a gaggle of managers, a shoal of lawyers, and a murder of sales "engineers", on a product already bringing in revenue.
In other words, a startup company that has succeeded in making some sales, usually to corporations or government which will pay for maintenance contracts (hence some revenue stream after the initial sale) and that is most likely growing too fast and too hard and can't keep up with the customer requirements and bug fixes but hasn't yet hired the gaggle, shoals, and murders that a well greased "where did my productivity go?" company requires.
Which brings me to my Alice in Wonderland conclusion, that developer productivity can only be measured in that awkward, painful, stressful, and insane period when a company has "hit it" but hasn't "gotten it", there is a minimal amount of obfuscation between the customer and the developer, the backlog of work is far beyond what the current team can accomplish without the tech to transfer brains upon death, and productivity is measured against "this has to get done by Friday or we lose the customer or sale." In that specific circumstance, productivity is easy to measure. You either succeeded to keep the customer or make the sale, or you failed. Binary. Black and white. You succeeded in producing the output or you didn't. You were productive or you weren't.
One final rabbit hole. Developer productivity is also meaningless because it assumes a manufacturing style of "input" and "output" over a given time period. Software isn't like that. It might take years to write a Google or Facebook, but once it's done, well, it's done. The "consumption" of the product is a web link or a 30 second download (unless you're Microsoft.) So how the heck do you measure productivity now when once the product (the software) is produced, the "output" is little more than a click that clones onto your hard drive (if even that) the pattern of 0 and 1 bits that define the product? Wow, my developers are insanely productive! We've had a million visitors to our site this year!!!
Which gets us to the evil of productivity -- is Marc more productive than Joe? Meaning, given similar tasks, does Marc get the job done faster and with similar "accuracy" than Joe, or not?
Which, going back to my Alice in Wonderland scenario, is not an issue when your developers are "expert islands" and the developer to island ratio is 1:1. You have no basis for comparison until your company get passed that birth process and the developer to island ratio is 2:1 or more.
And this ratio, by the way, defines "job security" vs. "eek, I'm replaceable", and therefore drives developers to be perceived as productive when in the "eek, I'm replaceable" corporate structure. Fortunately, there are many islands and the key to success (both for the developer and the corporation) is to have a healthy balance in the developer:island ratio, because developers want to feel unique and valued and not a cog in the machine, but a healthy level of stress and knowledge sharing is also socially rewarding. Which, in terms of psychology, makes for a happier and more productive developer! And ironically, in a corporate environment, leads to the conclusion that only the developer can tell you whether he/she "feels" productive and to what degree, so you're productivity measure in that scenario becomes entirely subjective. Which was the first sentence in this tome that just killed your productivity. 
modified 3-Nov-19 20:36pm.
|
|
|
|
|
Fitbit will develop Made by Google wearables for Wear OS, should the deal close successfully. Congratulations on taking 5000 steps. Here's an advertisement for ice cream.
|
|
|
|
|
|
Om my .. this story is really perplexing, unbelievable and logical at the same time...
|
|
|
|
|
0) It's the fault of the engineers for not specifying in the MCAS requirements that cross-checking systems was necessary.
1) It's Boeing's fault for OUT-SOURCING the development to Indian developers who barely know what a f*cking airplane even is, much less that have anything resembling even passing familiarity with avionics.
2) It's Boeing's fault for not sending aviation engineers to monitor the developers' work. THOSE would have been the guys to stand up and say, "Hey, this ain't right!"
3) It's Boeing's fault that management placed more importance on money than on safety. This probably led to "shortcuts" being implemented in order to meet unreasonable schedules. When presented with the age old conundrum regarding cost, features, and time, and that you can meet two of those three critreria, they practically stampeded to cut features in the interest of cost and time.
4) This is a very good example of how management screws up software, and then tries to blame the developer instead of management. I bet management all still got their huge-ass bonuses, too.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I hope you read the article.
|
|
|
|
|
Yeah, I read the article - they tried to fix bad hardware with software, and failed. Earlier articles on the subject tried to lay the blame at the feet of the programmers, but I (and every developer here) knew it was bullsh*t from the start.
0) Boeing screwed up the aerodynamics because they were trying to avoid the "not a 737 anymore" problem, because IT COST LESS MONEY.
1) Boeing decided to fix it with software, because it COST LESS MONEY
2) They outsourced the software development to India, because it COST LESS MONEY
3) All the things that happened as a result of or that caused the three items above were done to REDUCE COST TO BOEING.
4) Money over safety - same sh*t, different day.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: They outsourced the software development to India, because it COST LESS MONEY
Nowhere is it mentioned that they outsourced MCAS to India. They might have outsourced Payroll, HR or such non-technical stuff to India, not something as critical as MCAS, certainly not at $9 per hour.
modified 4-Nov-19 7:19am.
|
|
|
|
|
It was revealed in an article about it. No, I don't have a cite.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
