However, if the unions disappeared, the laws would still be in place.
Given that our current President is trying to undo almost everything from the past 30 years of progress, these laws could easily be gone. You can't assume the future will always be at least as bright as it is now.
Those laws can only go away if Congress makes it possible by passing more laws (to repeal those laws or make them overall benign). The POTUS cannot himself change law.
I mean the main inland ice sheet is 100,000 years old. Obviously, the edges of Greenland are much more sensitive to small temperature fluctuations and local climate changes.
Would love to see the proof - and not just suppositions, theories, etc - that it's 100,000 years old.
Problem is, you can't prove it. You can only extrapolate based on theories, hypotheses, and suppositions with math based on assumptions designed to support that conclusion.
The reason git won over svn and such is bisect, rebases and so on; svn is hardly better than a stack of daily tarballs.
Git and SVN are both excellent tools. Git won for FOSS because of being distributed being; but if you need centralized control than SVN is hands down the best tool out there. Most FOSS projects need a DVCS; many companies do too; yet there are still many cases where a centralized VCS system is the best choice - e.g I wouldn't want to try to have to deal with export control of code with Git; SVN makes it very easy.
Unlike BitKeeper's equivalent, git submodules are not transparent. If you're using submodules, then you constantly have to be aware of the submodule work flow. You also need to decide up front how to split your repo. About the only thing I miss from svn is being able to keep everything related to a project in one big repo, and either check out the whole thing or some small sub-project, depending on what I'm working on.
That's a good thing. SVN made svn:externals a little too transparent, and it foobar'd plenty of people that just didn't know how it worked. Making people aware of it is probably a good thing.
That said, I do find having to do the "git submodule " thing really annoying.
The whole point of git is that you have identical copy on your machine. Why take away git's biggest advantage?
The issue is that it doesn't well with how VS works which was based on how Visual Source Safe (VSS - Microsoft's version of CVS) worked, and it did locks per file as it pulled each file from the repository when you opened it.
Honestly, that's really the only reason I can see for why MS would want this. It makes it fit back into that old, broken model of locking files and tracking changes. Perhaps it has some benefit for how they track who did what/when, but it's not really something that is broken in git itself.
Their numbers for duration are probably no where near accurate on a properly maintained project, and may have a lot to do with failures in Windows and NTFS more than anything else.
But if multiple applications in Office share a library, where do you put that library so that the build process for each Office application can see it? Are submodules or subtrees a good choice, and if "yes," which is more appropriate?
You make that library a specific project, releasable on its own schedule, with a known distribution system that everyone can access for headers and binaries, and everyone uses releases of that project.
I did that under SVN at a previous position. I had 1 large Qt-based project that generated about 30 static libraries, about 20 standard C/C++ static library projects, a common headers project for the standard C/C++ static libraries, and about 10-50 programs that used the libraries and headers. All-in-all, it was about 400K SLOC. Keeping the interfaces tied to releases made it a lot simpler to manage the libraries, and treating everything as 3rd party dependencies made standardization and use of the interfaces extremely easy so I could maintain the whole thing by myself. Each "project" had its own home in SVN, and I used SVN's svn:externals functionality to pull everything together appropriately. So you'd pull the Qt project down and it'd pull the C/C++ Headers down too inside itself so that it had its version for compilation and would then independently compile; you'd pull another library down and it'd do the same thing for its compilation. The program itself would pull the headers project down, and then use those to link against everything else. Worked beautifully. No single project was more than 30k in size.
The more functionality you have the more this makes life simpler. So yeah - each DLL, SYS file, EXE, COM, etc in Windows should be its own independent project;.and they should interface using a standardized set of headers. What the library does within itself shouldn't matter as long as it adheres to the public interface. For example, I had one project that provided interfaces for a data file which had different versions; the version data was internal to the library, and the interface was standardized in a way that the internals of the file didn't matter. I could slowly rev the public interface while making massive changes internally when needed - even adding entirely new versions of the file format.
Works well when you *engineer* what you're doing. Not so well when you try to be a computer science artist and let things fall as they may.
Oh, and while I used SVN at that time, Git would do just as well with its Submodules functionality.
If you look at the history of the Vikings, you will notice an odd naming of Greenland
The Greenland ice sheet is 100,000 years old, so it was there when the Vikings visited it. The Vikings did find some green parts along the edges, but these are green today as well. See this documentary https://www.youtube.com/watch?...
Funny since we also have evidence (f.e https://news.slashdot.org/comm...) that directly contradicts that. Guess it's really only 100,000 years old if you accept evolutionary theory over reality, and the purposeful redesign of geological information the late 1800's and early 1900's to better position evolution as reality, versus the known historic records that directly contradict purported science.
I actually looked into this a couple of years ago, I'm not American but seeing the whole H-1B debate rage on here for years intrigued me. It turned out there are plenty of places online that seemed to list all H-1B visas issued by year including for which company and at what salary level.
It was clear that some companies such as those mentioned in the summary - Infosys and WiPro did indeed bring people over on H-1Bs to undercut the local market, and it's understandable why that would piss people off no end, I can fully agree with wanting to stop that kind of practice.
There's actually quite a few firms; Infosys and WiPro are just the most well known. I ran into one firm in SC where when interviewing with them it was evident they were doing the interview locals just for legal purposes, the entire firm was Indian workers and it was clear that's really all they intended on hiring, especially when you started looking at company culture, etc.
But they were only a small part of the story, what was also clear was that the vast majority of tech industry H-1Bs were going to big players like Google, Microsoft, Amazon, Apple, et. al. and when going to these companies, these companies were paying well above the national average salary for the roles in question - in many cases at least 2x higher, and certainly higher than the average local salaries (as best as I could find data on them) for those roles.
All the companies are guilty of playing games to get H1-B visas approved. I've known some great people working in the US on H1-B visas and knew they were being paid well. But that's not the norm, and often games are played with titles, etc. Especially with Software Developers being able to match up job titles between any two companies is extremely difficult - there's about 50 different job titles for the same job ranging from what sounds like grunt work (Programmer Analyst) to something fancy (Software Engineer), there's zero consistency so it's really hard to compare. What may seem like on paper to be equivalent may not be - the position may be something else entirely and significantly underpaid as a result.
So I think it's overly simplistic to make the argument that H-1Bs are bringing salaries down - on average they clearly weren't, and in fact most tech companies were using them for their intended purpose - to bring in foreign talent that they'd just have no hope of sourcing in sufficient number locally. There were clearly companies abusing the process like WiPro and Infosys but they were a minority, and their abuse can be dealt with without affecting the competitiveness of the players using the system as intended.
H1-B's have long been a problem. Disney replaced an entire department with outsourced H1-B workers for no reason than cutting costs. (IIRC, they got sued over that one, but I doubt it restored any jobs in the end.) Microsoft has been pushing for H1-B's for a long time. The issue is not necessarily that there are not STEM workers, it's that the STEM workers may not be where the company is and don't necessarily want to move. I'll never move to Seattle, WA area for many reasons (politics included); which means it would be extremely hard for me to be able to take a job at Microsoft since most of their devs are located in the Seattle area.
Now I've long held the workers need to be willing to move. But companies need to too. They need to go to the workers as much as the workers need to go to the companies. For Microsoft, that's hard - they've got a sweet deal with Seattle and the State of Washington that lets them avoid a lot of taxes. Apple is probably not that different with CA and Cupertino. But that's also means they can't complain if they can't find enough workers - there is no reason they can't have multiple major offices throughout the US to do the work and be able to fill the positions. They'll also get cheaper work at times for the same skill levels since they can move into depressed are
I do not know (or care, now) if Google Docs has a subscription service that would ease minds about those concerns.
Any cloud-based service will *never* be able to overcome those concerns, which for companies I do agree is something that must be very strongly looked into.
That said, Google and other cloud-based service providers also typically offers an appliance device - a few servers that provide the same service but runs in your own server room. (https://www.google.com/cloud/ - though you'd probably have to specifically ask about on-premise appliances...only docs I could find on it were a few years old.)
So yes, while there are concerns there's also methods of overcoming those concerns, though not for free.
CDs should be better in every aspect than an LP/Cassette...but they producers typically cut out a bunch of stuff that ultimately makes them inferior. And there are ways around each of the issues you mentioned - hiss was essentially dead space when the volume was turned up too loud.
Personally, I've got a bunch of LPs and Cassettes I want to digitize, and they'll all be better than any CD I could buy.
Neither do MP3s. And the quality's better. But, I guess they're not "tangible."
Well...let's see an uncompressed, unfiltered, band-unlimited, DRM-less analog audio stream from a cassette, or a compressed, filtered, band-limited CD or MP3?
Yeah...LPs and Cassettes are coming back b/c of how the CDs and MP3s are getting cut.
- Frequency bands deemed to high or low are cut off - removing high pitches and low pitches that while you may not be able to *hear* you can feel in some senses.
- Filters take this to another level and can often degrade it; sometimes these are used to keep people from copying them as extracting from the CD may add pops, glitches, etc (yes, I have a CD that way - no matter how good I rip it it sill has pops, etc b/c of the watermarks due to the filters applied).
- Compression is also applied, and usually is lossy. AAC, IIRC, was better than MP3 b/c it was lossless, but even then - CDs are compressed typically with lossy compressions.
Do yeah - digital tracks could be better than LP and Cassette but often aren't b/c of everything done by the studios. Yes, you can skip a lot of that stuff but then you get a lot less audio on CDs or the MP3s/AACs get to be a lot larger.
Most of all that is FOSS, with the exception of Adobe (of course).
Exactly, and by organizations that have a well defined CVE policy so they generate a lot more CVEs than proprietary companies (like MSFT, Apple, Oracle, etc).
Oh, and don't forget that probably all those Linux Kernel CVEs also had a Debian/Ubuntu/Red Hat CVE filed too - so multiple countings - since CVEs are a form of notification; often by the time the CVE is filed for a FOSS project it has also already been fixed; unlike non-FOSS organizations...
...they already had this functionality built into an existing app - G+ I think. This just makes it easier to manage...finding the setting in the existing app is always a PITA and it's not easy to manage at all. So yeah, it'd be great to have this better supported.
Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases
Hey, but PostgreSQL is buzzword compliant with the new hipness... you want a JSON-based document store?
CREATE TABLE docstore (
docid SERIAL PRIMARY KEY,
userid INTEGER REFERENCES users,
document JSON
);
OK, don't code-review that off-the-cuff doodle too seriously, but implementing NoSQL features in a decent RDBMS is easy, implementing RDBMS features in NoSQL is hard...
Yep. I've worked two projects now that include Cassandra. Why? Replication. All the queries are SQL/Relational oriented. The one project supported Sqlite (for dev testing), Mongo, and Cassandra but they wanted to deploy with Cassandra; the project got canned after it was nearly complete and they started looking at the operational costs to meet our required throughput (requests/second) because of how massive the Cassandra cluster needed to be (in terms of node count and the type of server needed to support it); though we were officially told it was canned for other reasons, the timing was just too close to not have been a major factor in the decision.
"theoretical ways to deal with the waste products" = "no actual ways to deal with the waste products"
Actually there are very simple ways to take care of the waste products, but either (a) environmentalists and the EPA get in the way, or (b) we've removed them as options via International Treaty.
The simplest way to deal with waste products is ship into space - and we ship usable nuclear material - working nuclear reactors - into space regularly for use by satellites, etc. So yes, it is a perfectly viable to method to get rid of it - sent into a dedicated orbit around the solar system or to be consumed by the Sun at some point (months) in the future. However, this is banned by International Treaty - one of several treaties signed during the Cold War, primarily to keep nations from sending Nuclear Missiles into space for use (f.e see the movie Space Cowboys - yeah, not doable by Treaty).
So yes, there are ways to deal with it if we decided we really wanted to actually deal with the waste products.
They have 1.2 million users. That's big enough to have an "email server admin." In fact, it's big enough to have two. They should get some. Not having any hasn't worked out too well for them.
Well....if they're using MS Exchange they'd need a team of 4 or 5 at least. So yes, someone should have known how to set the groups properly so that this could not happen. Of course, that's assuming it went to "Everyone" or a similar all-encompassing group. It could just as easily been a single email that contains a bunch of groups too...read TFA to find out (I would assume).
A Democracy means that there is direct elections - every vote directly influences the voter outcome.
What we have is a Representative Democracy in the form of a Republic where elections are for representatives that are tasked with making the real choices - there is no required direct election of the representatives. Yes, some representatives are directly elected; others are not. Voter influence is by design indirect.
In an enterprise there are two big costs... licensing, and support.
Linux the cost of support is pretty high -- for models like Red Hat the cost often is higher than Windows because you don't get as high a per-seat discount. Then there are the other ancillary costs like productivity, accessibility, data governance, etc... which are harder to materialize but also make an impact.
So here's the thing:
With Linux - you *might* have a support cost (e.g RHEL/SuSE/Canonical Enterprise support agreements), infrastructure to run, a few engineers to maintain your specific packages, and your normal support staff.
With Windows, you still actually have all of that, plus you have to the licensing for Windows itself, the servers, etc. Windows Server requires licenses for clients to access it - so you pay twice for each user (WIndows Desktop License + CAL on the server).
The enterprise support agreement costs between RHEL/SuSE/Canonical and Microsoft are actually pretty comparable. So ultimately you *do* save money.
However, most organizations that deploy Linux don't heavily customize it like Munich did with making LiMux. Most will just use what's provided via one of those Enterprise distros, use their support, and infra, etc. They might deploy a local mirror (to reduce bandwidth charges and be friendly), and may be a repo for their software additions - but not likely.
So ultimately arguing that people and infrastructure makes Linux more expensive to deploy than Windows is also inherently false. Aside from the licensing (not support, but actual licenses) cost everything runs generally the same; if anything you'll need *more* people to operate the Windows systems simply b/c one Windows administrator has a lot more work to do to maintain a Windows environment than 1 Linux/Unix administrator ever has - which is why you typically see a 1:50 to 1:100 admin to system ratio with Windows (and I'm being generous) while you normally will see a 1:500, 1:1000, or even 1:10,000 with Linux/Unix.
Well, let me see how really detached I am from technical work:
At start of project:
My estimate: 490 Story points, +2 senior developers, +1 senior QA, 3rd party cost $20k, GA in 9 months
The team estimate: 305 Story points, no new headcount needed, 3rd party cost 15k, GA in 8 months
It's a matter of how much dev work you are doing versus management work. The more time you spend doing solely management, the less you'll be in touch with real dev estimates, etc as it's impossible to keep up both skill sets without actually using them.
I constantly have to tell the team their estimates are low and unrealistic, as I hear them not discussing corner cases, they take it as an insult to their pride that their estimates are accurate, yet 5 releases down the line they consistently underestimate by as much as 80% and miss release dates by as much as 9 months. Where we were supposed to have a team if 16 senior people, now we have an ever growing team that lastly counted 40 junior people. Every 2-3 months RND management see that they are behind, go out and find some guy fresh out of college, 2 or 3 other developers take 2 months to train the new hire, and as a result we are getting even farther behind, while the new guy is only interested in refactoring to the latest technology buzzword instead of writing new functionality. Refactoring is important, but I generally prefer to have the most senior guys do it, and only after they have been tasked by the Architect to do so.
Sounds like (a) you need some good lessons learned taught among the team, and (b) you need to be applying the standard practice of PM Estimate = ((Dev Estimate * 2) + 20%). Devs are extremely bad at and are not taught how to estimate effort; spend the time to teach them how instead of complaining about them.
Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.
That's the wrong way around. If you're the project manager, you got hired partly for your people skills. Developers get hired primarily for their technical skills. It would be easier for a good project manager to learn to speak geek than for developers to speak business.
Devs still need to learn the language of management. Even if they don't go into management it will significantly help with (a) understanding management, and (b) communicating with management; thereby making life a lot nicer. It helps when talking to the PM too; but the PM should be able to talk with the Devs in their lingo - IOW, Dev-Dev is pure dev speak; Dev-PM is mixed dev speak and management speak; PM-Management is pure management speak.
Besides, developers tend to be worse negotiators, and if they're talking a foreign language they'll be even more at a disadvantage. One defense a bad negotiator has is to take a position and stick to it.
Experienced developers are sometimes gun-shy. If you're trying to do a job, and say "We can do it if we get X and Y", and find that you're expected to do it just fine without X and Y, and your complaints get stonewalled, it's going to be much easier for you to say "No, can't do it" next time.
It's possible to wind up in a situation where developers and managers are on the same side, but that usually requires management to understand developers and keep promises.
Consider that many senior devs will eventually do some level of management; it helps to learn the lingo. You may not be good at negotiating right away, but building up the toolset is a good thing nonetheless.
What I have found out, there are some cultures that say "No" when in fact they mean that they won't be able to do it with current resources. Which is absolutely fine to disclose, but for some reason, they don't do it. They just say "no".
Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.
Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.
Aside from the MBA speak you have in there...you are obviously detached from the team in any meaningful manner. You might have had a technical background at some point, but you've lost it due to going down the PM/MBA path, and have forgotten how hard it is for developers to do any kind of estimates.
That is why you have senior developers and software architects that are in charge of the project as a whole and its general road map. You as the PM need to be working with those people - 1 or 2 people that will really know the product, its source, and customer base really well - to get the estimates, etc you need. They should in turn be training the lower devs to be able to do the same (though that almost never happens) while they collaborate to get the estimate figured out.
Then it is up to the PM to present and defend that cost to execs in a cost/value analysis and if numbers work out the PM can actually help the team get funded and get the job done. But if the team only says "no" instead of "yes, but..." by providing a complete analysis for a means to make it a "yes" sometimes it just doesn't get to a "yes" and the whole product gets scrapped.
Wrong. The PM is but one part of the team in deciding on the estimate. Their job is to help identify what is valuable to go after and work with the team to build up an estimate and make the case. Their job is to run the financials for the team, ensure there's enough developers and resources, etc. Their job is to be the voice of the team to fight for the product in the organization, to ensure it get appropriately marketed and arrange for all the other non-technical stuff that goes into the product while working with the team to get the technical stuff completed.
Sadly, this is where the MBA/PM courses fail. They focus too much on looking at this in an unbiased manner based on balanced sheets; team work is against other CxO's, and the people that do the real work are turned into "resources" that can be "allocated" without any information or regard for what those "resources" really are. That's not to say that there is not a place for that kind of perspective (there is) but it's not how you should be looking at it the vast majority of the time.
Even if you can reproduce all of the hardware exactly, you are never going to get the same kinds of results that putting software in the hands of real users will get you.
There's different kinds of buys, which is why you have different kinds of systems and testing environments.
A dev should be able to have an isolated environment in which to be able to test the various parts. Each part should be able to have a sufficient emulation of external parts to be able to have its own unit and functional testing. From there, several parts should be integrated at a time to do functional and integration testing, eventually building up to the entire system being fully integrated and using emulated externals (e.g external auth emulation) so the system can itself run in isolation. This gets to 95% of the issues.
From here is scalability - for which the operations team should be providing environments sufficient to do the scaling testing so stuff can be tested at sufficient scale before it hits production.
Now, that doesn't mean you won't end up with issues in production, but that it should be a rare thing for that to happen. In those rare cases you may have to test in production, but that should be the exception, not the rule.
Too often we don't invest in all the different levels of testing b/c (a) devs are lazy, and (b) management cheaps out. However, doing all the layers of testing will be cheaper in the end since things will be caught earlier where it's cheaper and faster to fix.
Slashdot Mirror
After the snowden reveal, I switched to it exclusively when communicating with a friend of mine.
The NSA is not interested in your cat videos.
That may be...but they'd have to decrypt it first to determine that...
However, if the unions disappeared, the laws would still be in place.
Given that our current President is trying to undo almost everything from the past 30 years of progress, these laws could easily be gone. You can't assume the future will always be at least as bright as it is now.
Those laws can only go away if Congress makes it possible by passing more laws (to repeal those laws or make them overall benign). The POTUS cannot himself change law.
I mean the main inland ice sheet is 100,000 years old. Obviously, the edges of Greenland are much more sensitive to small temperature fluctuations and local climate changes.
Would love to see the proof - and not just suppositions, theories, etc - that it's 100,000 years old.
Problem is, you can't prove it. You can only extrapolate based on theories, hypotheses, and suppositions with math based on assumptions designed to support that conclusion.
Unlike BitKeeper's equivalent, git submodules are not transparent. If you're using submodules, then you constantly have to be aware of the submodule work flow. You also need to decide up front how to split your repo. About the only thing I miss from svn is being able to keep everything related to a project in one big repo, and either check out the whole thing or some small sub-project, depending on what I'm working on.
That's a good thing. SVN made svn:externals a little too transparent, and it foobar'd plenty of people that just didn't know how it worked. Making people aware of it is probably a good thing.
That said, I do find having to do the "git submodule " thing really annoying.
The whole point of git is that you have identical copy on your machine. Why take away git's biggest advantage?
The issue is that it doesn't well with how VS works which was based on how Visual Source Safe (VSS - Microsoft's version of CVS) worked, and it did locks per file as it pulled each file from the repository when you opened it.
Honestly, that's really the only reason I can see for why MS would want this. It makes it fit back into that old, broken model of locking files and tracking changes. Perhaps it has some benefit for how they track who did what/when, but it's not really something that is broken in git itself.
Their numbers for duration are probably no where near accurate on a properly maintained project, and may have a lot to do with failures in Windows and NTFS more than anything else.
But if multiple applications in Office share a library, where do you put that library so that the build process for each Office application can see it? Are submodules or subtrees a good choice, and if "yes," which is more appropriate?
You make that library a specific project, releasable on its own schedule, with a known distribution system that everyone can access for headers and binaries, and everyone uses releases of that project.
I did that under SVN at a previous position. I had 1 large Qt-based project that generated about 30 static libraries, about 20 standard C/C++ static library projects, a common headers project for the standard C/C++ static libraries, and about 10-50 programs that used the libraries and headers. All-in-all, it was about 400K SLOC. Keeping the interfaces tied to releases made it a lot simpler to manage the libraries, and treating everything as 3rd party dependencies made standardization and use of the interfaces extremely easy so I could maintain the whole thing by myself. Each "project" had its own home in SVN, and I used SVN's svn:externals functionality to pull everything together appropriately. So you'd pull the Qt project down and it'd pull the C/C++ Headers down too inside itself so that it had its version for compilation and would then independently compile; you'd pull another library down and it'd do the same thing for its compilation. The program itself would pull the headers project down, and then use those to link against everything else. Worked beautifully. No single project was more than 30k in size.
The more functionality you have the more this makes life simpler. So yeah - each DLL, SYS file, EXE, COM, etc in Windows should be its own independent project;.and they should interface using a standardized set of headers. What the library does within itself shouldn't matter as long as it adheres to the public interface. For example, I had one project that provided interfaces for a data file which had different versions; the version data was internal to the library, and the interface was standardized in a way that the internals of the file didn't matter. I could slowly rev the public interface while making massive changes internally when needed - even adding entirely new versions of the file format.
Works well when you *engineer* what you're doing. Not so well when you try to be a computer science artist and let things fall as they may.
Oh, and while I used SVN at that time, Git would do just as well with its Submodules functionality.
If you look at the history of the Vikings, you will notice an odd naming of Greenland
The Greenland ice sheet is 100,000 years old, so it was there when the Vikings visited it. The Vikings did find some green parts along the edges, but these are green today as well. See this documentary https://www.youtube.com/watch?...
Funny since we also have evidence (f.e https://news.slashdot.org/comm...) that directly contradicts that. Guess it's really only 100,000 years old if you accept evolutionary theory over reality, and the purposeful redesign of geological information the late 1800's and early 1900's to better position evolution as reality, versus the known historic records that directly contradict purported science.
I actually looked into this a couple of years ago, I'm not American but seeing the whole H-1B debate rage on here for years intrigued me. It turned out there are plenty of places online that seemed to list all H-1B visas issued by year including for which company and at what salary level.
It was clear that some companies such as those mentioned in the summary - Infosys and WiPro did indeed bring people over on H-1Bs to undercut the local market, and it's understandable why that would piss people off no end, I can fully agree with wanting to stop that kind of practice.
There's actually quite a few firms; Infosys and WiPro are just the most well known. I ran into one firm in SC where when interviewing with them it was evident they were doing the interview locals just for legal purposes, the entire firm was Indian workers and it was clear that's really all they intended on hiring, especially when you started looking at company culture, etc.
But they were only a small part of the story, what was also clear was that the vast majority of tech industry H-1Bs were going to big players like Google, Microsoft, Amazon, Apple, et. al. and when going to these companies, these companies were paying well above the national average salary for the roles in question - in many cases at least 2x higher, and certainly higher than the average local salaries (as best as I could find data on them) for those roles.
All the companies are guilty of playing games to get H1-B visas approved. I've known some great people working in the US on H1-B visas and knew they were being paid well. But that's not the norm, and often games are played with titles, etc. Especially with Software Developers being able to match up job titles between any two companies is extremely difficult - there's about 50 different job titles for the same job ranging from what sounds like grunt work (Programmer Analyst) to something fancy (Software Engineer), there's zero consistency so it's really hard to compare. What may seem like on paper to be equivalent may not be - the position may be something else entirely and significantly underpaid as a result.
So I think it's overly simplistic to make the argument that H-1Bs are bringing salaries down - on average they clearly weren't, and in fact most tech companies were using them for their intended purpose - to bring in foreign talent that they'd just have no hope of sourcing in sufficient number locally. There were clearly companies abusing the process like WiPro and Infosys but they were a minority, and their abuse can be dealt with without affecting the competitiveness of the players using the system as intended.
H1-B's have long been a problem. Disney replaced an entire department with outsourced H1-B workers for no reason than cutting costs. (IIRC, they got sued over that one, but I doubt it restored any jobs in the end.) Microsoft has been pushing for H1-B's for a long time. The issue is not necessarily that there are not STEM workers, it's that the STEM workers may not be where the company is and don't necessarily want to move. I'll never move to Seattle, WA area for many reasons (politics included); which means it would be extremely hard for me to be able to take a job at Microsoft since most of their devs are located in the Seattle area.
Now I've long held the workers need to be willing to move. But companies need to too. They need to go to the workers as much as the workers need to go to the companies. For Microsoft, that's hard - they've got a sweet deal with Seattle and the State of Washington that lets them avoid a lot of taxes. Apple is probably not that different with CA and Cupertino. But that's also means they can't complain if they can't find enough workers - there is no reason they can't have multiple major offices throughout the US to do the work and be able to fill the positions. They'll also get cheaper work at times for the same skill levels since they can move into depressed are
I do not know (or care, now) if Google Docs has a subscription service that would ease minds about those concerns.
Any cloud-based service will *never* be able to overcome those concerns, which for companies I do agree is something that must be very strongly looked into.
That said, Google and other cloud-based service providers also typically offers an appliance device - a few servers that provide the same service but runs in your own server room. (https://www.google.com/cloud/ - though you'd probably have to specifically ask about on-premise appliances...only docs I could find on it were a few years old.)
So yes, while there are concerns there's also methods of overcoming those concerns, though not for free.
CDs should be better in every aspect than an LP/Cassette...but they producers typically cut out a bunch of stuff that ultimately makes them inferior. And there are ways around each of the issues you mentioned - hiss was essentially dead space when the volume was turned up too loud.
Personally, I've got a bunch of LPs and Cassettes I want to digitize, and they'll all be better than any CD I could buy.
Neither do MP3s. And the quality's better. But, I guess they're not "tangible."
Well...let's see an uncompressed, unfiltered, band-unlimited, DRM-less analog audio stream from a cassette, or a compressed, filtered, band-limited CD or MP3?
Yeah...LPs and Cassettes are coming back b/c of how the CDs and MP3s are getting cut.
- Frequency bands deemed to high or low are cut off - removing high pitches and low pitches that while you may not be able to *hear* you can feel in some senses.
- Filters take this to another level and can often degrade it; sometimes these are used to keep people from copying them as extracting from the CD may add pops, glitches, etc (yes, I have a CD that way - no matter how good I rip it it sill has pops, etc b/c of the watermarks due to the filters applied).
- Compression is also applied, and usually is lossy. AAC, IIRC, was better than MP3 b/c it was lossless, but even then - CDs are compressed typically with lossy compressions.
Do yeah - digital tracks could be better than LP and Cassette but often aren't b/c of everything done by the studios. Yes, you can skip a lot of that stuff but then you get a lot less audio on CDs or the MP3s/AACs get to be a lot larger.
Windows 10 had Less vulnerabilities that linux and Mac... AHAHAHAHAHAHAHA
And Microsoft has a very strict policy on what gets filed for a CVE; while open source folks file CVEs very often.
Most of all that is FOSS, with the exception of Adobe (of course).
Exactly, and by organizations that have a well defined CVE policy so they generate a lot more CVEs than proprietary companies (like MSFT, Apple, Oracle, etc).
Oh, and don't forget that probably all those Linux Kernel CVEs also had a Debian/Ubuntu/Red Hat CVE filed too - so multiple countings - since CVEs are a form of notification; often by the time the CVE is filed for a FOSS project it has also already been fixed; unlike non-FOSS organizations...
...they already had this functionality built into an existing app - G+ I think. This just makes it easier to manage...finding the setting in the existing app is always a PITA and it's not easy to manage at all. So yeah, it'd be great to have this better supported.
That actually could still be only generated by waze users.
I use Google Maps, don't even have Waze installed. :P
Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases
Hey, but PostgreSQL is buzzword compliant with the new hipness... you want a JSON-based document store? CREATE TABLE docstore ( docid SERIAL PRIMARY KEY, userid INTEGER REFERENCES users, document JSON );
OK, don't code-review that off-the-cuff doodle too seriously, but implementing NoSQL features in a decent RDBMS is easy, implementing RDBMS features in NoSQL is hard...
Yep. I've worked two projects now that include Cassandra. Why? Replication. All the queries are SQL/Relational oriented. The one project supported Sqlite (for dev testing), Mongo, and Cassandra but they wanted to deploy with Cassandra; the project got canned after it was nearly complete and they started looking at the operational costs to meet our required throughput (requests/second) because of how massive the Cassandra cluster needed to be (in terms of node count and the type of server needed to support it); though we were officially told it was canned for other reasons, the timing was just too close to not have been a major factor in the decision.
"theoretical ways to deal with the waste products" = "no actual ways to deal with the waste products"
Actually there are very simple ways to take care of the waste products, but either (a) environmentalists and the EPA get in the way, or (b) we've removed them as options via International Treaty.
The simplest way to deal with waste products is ship into space - and we ship usable nuclear material - working nuclear reactors - into space regularly for use by satellites, etc. So yes, it is a perfectly viable to method to get rid of it - sent into a dedicated orbit around the solar system or to be consumed by the Sun at some point (months) in the future. However, this is banned by International Treaty - one of several treaties signed during the Cold War, primarily to keep nations from sending Nuclear Missiles into space for use (f.e see the movie Space Cowboys - yeah, not doable by Treaty).
So yes, there are ways to deal with it if we decided we really wanted to actually deal with the waste products.
They have 1.2 million users. That's big enough to have an "email server admin." In fact, it's big enough to have two. They should get some. Not having any hasn't worked out too well for them.
Well....if they're using MS Exchange they'd need a team of 4 or 5 at least. So yes, someone should have known how to set the groups properly so that this could not happen. Of course, that's assuming it went to "Everyone" or a similar all-encompassing group. It could just as easily been a single email that contains a bunch of groups too...read TFA to find out (I would assume).
WE DO HAVE A DEMOCRACY. AMERICA IS A DEMOCRACY.
No, we do not.
A Democracy means that there is direct elections - every vote directly influences the voter outcome.
What we have is a Representative Democracy in the form of a Republic where elections are for representatives that are tasked with making the real choices - there is no required direct election of the representatives. Yes, some representatives are directly elected; others are not. Voter influence is by design indirect.
In an enterprise there are two big costs... licensing, and support.
Linux the cost of support is pretty high -- for models like Red Hat the cost often is higher than Windows because you don't get as high a per-seat discount. Then there are the other ancillary costs like productivity, accessibility, data governance, etc... which are harder to materialize but also make an impact.
So here's the thing:
With Linux - you *might* have a support cost (e.g RHEL/SuSE/Canonical Enterprise support agreements), infrastructure to run, a few engineers to maintain your specific packages, and your normal support staff.
With Windows, you still actually have all of that, plus you have to the licensing for Windows itself, the servers, etc. Windows Server requires licenses for clients to access it - so you pay twice for each user (WIndows Desktop License + CAL on the server).
The enterprise support agreement costs between RHEL/SuSE/Canonical and Microsoft are actually pretty comparable. So ultimately you *do* save money.
However, most organizations that deploy Linux don't heavily customize it like Munich did with making LiMux. Most will just use what's provided via one of those Enterprise distros, use their support, and infra, etc. They might deploy a local mirror (to reduce bandwidth charges and be friendly), and may be a repo for their software additions - but not likely.
So ultimately arguing that people and infrastructure makes Linux more expensive to deploy than Windows is also inherently false. Aside from the licensing (not support, but actual licenses) cost everything runs generally the same; if anything you'll need *more* people to operate the Windows systems simply b/c one Windows administrator has a lot more work to do to maintain a Windows environment than 1 Linux/Unix administrator ever has - which is why you typically see a 1:50 to 1:100 admin to system ratio with Windows (and I'm being generous) while you normally will see a 1:500, 1:1000, or even 1:10,000 with Linux/Unix.
Well, let me see how really detached I am from technical work: At start of project: My estimate: 490 Story points, +2 senior developers, +1 senior QA, 3rd party cost $20k, GA in 9 months The team estimate: 305 Story points, no new headcount needed, 3rd party cost 15k, GA in 8 months
It's a matter of how much dev work you are doing versus management work. The more time you spend doing solely management, the less you'll be in touch with real dev estimates, etc as it's impossible to keep up both skill sets without actually using them.
I constantly have to tell the team their estimates are low and unrealistic, as I hear them not discussing corner cases, they take it as an insult to their pride that their estimates are accurate, yet 5 releases down the line they consistently underestimate by as much as 80% and miss release dates by as much as 9 months. Where we were supposed to have a team if 16 senior people, now we have an ever growing team that lastly counted 40 junior people. Every 2-3 months RND management see that they are behind, go out and find some guy fresh out of college, 2 or 3 other developers take 2 months to train the new hire, and as a result we are getting even farther behind, while the new guy is only interested in refactoring to the latest technology buzzword instead of writing new functionality. Refactoring is important, but I generally prefer to have the most senior guys do it, and only after they have been tasked by the Architect to do so.
Sounds like (a) you need some good lessons learned taught among the team, and (b) you need to be applying the standard practice of PM Estimate = ((Dev Estimate * 2) + 20%). Devs are extremely bad at and are not taught how to estimate effort; spend the time to teach them how instead of complaining about them.
That's the wrong way around. If you're the project manager, you got hired partly for your people skills. Developers get hired primarily for their technical skills. It would be easier for a good project manager to learn to speak geek than for developers to speak business.
Devs still need to learn the language of management. Even if they don't go into management it will significantly help with (a) understanding management, and (b) communicating with management; thereby making life a lot nicer. It helps when talking to the PM too; but the PM should be able to talk with the Devs in their lingo - IOW, Dev-Dev is pure dev speak; Dev-PM is mixed dev speak and management speak; PM-Management is pure management speak.
Besides, developers tend to be worse negotiators, and if they're talking a foreign language they'll be even more at a disadvantage. One defense a bad negotiator has is to take a position and stick to it.
Experienced developers are sometimes gun-shy. If you're trying to do a job, and say "We can do it if we get X and Y", and find that you're expected to do it just fine without X and Y, and your complaints get stonewalled, it's going to be much easier for you to say "No, can't do it" next time.
It's possible to wind up in a situation where developers and managers are on the same side, but that usually requires management to understand developers and keep promises.
Consider that many senior devs will eventually do some level of management; it helps to learn the lingo. You may not be good at negotiating right away, but building up the toolset is a good thing nonetheless.
What I have found out, there are some cultures that say "No" when in fact they mean that they won't be able to do it with current resources. Which is absolutely fine to disclose, but for some reason, they don't do it. They just say "no".
Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.
Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.
Aside from the MBA speak you have in there...you are obviously detached from the team in any meaningful manner. You might have had a technical background at some point, but you've lost it due to going down the PM/MBA path, and have forgotten how hard it is for developers to do any kind of estimates. That is why you have senior developers and software architects that are in charge of the project as a whole and its general road map. You as the PM need to be working with those people - 1 or 2 people that will really know the product, its source, and customer base really well - to get the estimates, etc you need. They should in turn be training the lower devs to be able to do the same (though that almost never happens) while they collaborate to get the estimate figured out.
Then it is up to the PM to present and defend that cost to execs in a cost/value analysis and if numbers work out the PM can actually help the team get funded and get the job done. But if the team only says "no" instead of "yes, but ..." by providing a complete analysis for a means to make it a "yes" sometimes it just doesn't get to a "yes" and the whole product gets scrapped.
Wrong. The PM is but one part of the team in deciding on the estimate. Their job is to help identify what is valuable to go after and work with the team to build up an estimate and make the case. Their job is to run the financials for the team, ensure there's enough developers and resources, etc. Their job is to be the voice of the team to fight for the product in the organization, to ensure it get appropriately marketed and arrange for all the other non-technical stuff that goes into the product while working with the team to get the technical stuff completed.
Sadly, this is where the MBA/PM courses fail. They focus too much on looking at this in an unbiased manner based on balanced sheets; team work is against other CxO's, and the people that do the real work are turned into "resources" that can be "allocated" without any information or regard for what those "resources" really are. That's not to say that there is not a place for that kind of perspective (there is) but it's not how you should be looking at it the vast majority of the time.
Even if you can reproduce all of the hardware exactly, you are never going to get the same kinds of results that putting software in the hands of real users will get you.
There's different kinds of buys, which is why you have different kinds of systems and testing environments.
A dev should be able to have an isolated environment in which to be able to test the various parts. Each part should be able to have a sufficient emulation of external parts to be able to have its own unit and functional testing. From there, several parts should be integrated at a time to do functional and integration testing, eventually building up to the entire system being fully integrated and using emulated externals (e.g external auth emulation) so the system can itself run in isolation. This gets to 95% of the issues.
From here is scalability - for which the operations team should be providing environments sufficient to do the scaling testing so stuff can be tested at sufficient scale before it hits production.
Now, that doesn't mean you won't end up with issues in production, but that it should be a rare thing for that to happen. In those rare cases you may have to test in production, but that should be the exception, not the rule.
Too often we don't invest in all the different levels of testing b/c (a) devs are lazy, and (b) management cheaps out. However, doing all the layers of testing will be cheaper in the end since things will be caught earlier where it's cheaper and faster to fix.