Once upon a time, 'powerful' computers were a precious resource that could not be dedicated to a single person, and so these impossibly dumb terminals were all people were allowed.
Then as things advanced, that model became obsolete, as devices much more powerful than the old powerful computers were so cheap, it just made sense to have everyone use dedicated computing devices, empowering the users and enabling a thriving home computer market of self-empowered users.
On the networking front, things started with BBSes and more relevant to most, walled garden environments like AOL and Prodigy. The scope of what they could provide was limited by network limitations, but to the extent communications and information flowed, it was controlled by your service provider with an iron fist. You *had* to pay AOL money if you wanted anyone to be able to find your data by keywords online, as an example.
Then as networking advanced, federated technologies like WWW and IRC prevailed, and suddenly the barriers of competition were reduced again and people could communicate and change who got their money and attention on a whim without repercussions. The late 90s were defined by standards and federated approaches displacing proprietary and isolated technologies. It represented a time where companies that had locked down their corners of the market had their customer base opened up to competition. Without this, Google, Twitter, Facebook, LinkedIn, and so forth never would have been able to start, it would have just been all-AOL.
In this century, we've seen a select few corporate interests get back much of the control. Google has become the de facto gatekeeper to the web, software vendors now don't need to let users download or can require their software to checkin and implement a 'rental-only' model for software, and applications that were once federated or at least could be instantiated by many are dominated instead by locked-in solutions (e.g. Slack is so much better than IRC, but is controlled by a single corporate interest, though MatterMost is pretty good at least...). Every little voice recognition clip is uploaded to remote servers for processing despite the fact the edge devices are orders of magnitude more powerful than systems that were doing voice dictation 20 years ago. We have been trained to treat multiprocessor multi-gigahertz devices with gigabytes of ram as dumb terminals not appropriate for any remotely serious task.
No, the old ways aren't better from a UI perspective or an experience perspective, but make no mistake that the power dynamic change that has come with it has downsides, and that's not so much the fault of the technology, just the usual power dynamic of human nature reasserting itself after a brief period where things were taken by surprise.
If I had to bet, I'd bet on browser embedded in the client rather than a remote video. You can do almost anything you could need in a mobile device using a web browser with javascript.
A remote video solution would be utterly terrible (it's not even seemless on local high speed networks, over mobile networks it's atrocious no matter who the vendor is).
It's called 'Chrome' (as others have pointed out).
What Google *specifically* promised was run an application without installing under android. I presume we are talking about a read chunks of the application on demand rather than requiring the whole thing to download in advance, so the application would think the device just has *really* slow storage for accessing the application payload.
However it could be as simple as changing the UI to make the download be invisible to the user (which is how web apps work, they get downloaded and cached when possible on load rather than have a distinct 'install' phase) and the 'feature' only working with small apps where that's reasonably possible.
Eh, we know what he meant, a modern web browser with javascript effectively being a runtime environment to produce applications that act pretty much exactly like a desktop application if desired. It's of course erroneous to say 'apps you don't download', since the apps are downloaded and cached, it just doesn't make a production out of it. Which is of course going to be the case for WeChat or Google or *anything* for that matter (after all a processor cannot run code that it can't read).
I know that if you described something like this to the original www team at the time they'd wonder at how their original vision of 'gopher++' turned into *this*.
A lot of people make the mistake of judging Chinese output by the quality of what is done there as paid for by western companies. In effect, many western companies are pretty much getting scammed by getting the worst of the worst in China, and the western company doesn't realize they are getting the bottom of the barrel because they also buy into the 'China just isn't that good' story.
Meanwhile native Chinese companies understand the lay of the land and can be quite competitive by leaving the bottom of the barrel to the foreign companies to deal with.
It's the biggest pitfall of offshoring to any nation that the leadership is not intimately familiar with. If the business leadership has stereotypes about a popular offshoring destinations, they can get pretty much scammed into thinking they have average work for the region when they really get the rejects that aren't employable by the good local companies.
To be fair to Romety, Palmisano was the one who set a crash course and 'roadmap 2015', got investors pumped and then promptly bailed probably knowing full well there was no realistic plan to deliver what he promised, but now it wouldn't be his fault. A lot of us were saying that Palmisano was nuts when he made that promise, then when he bailed we decided he was being personally very smart and was just setting up the next person to be the fall guy. Rometty stood by the pledge he made longer than she should have and the company was more and more damaged as a result, so she hasn't been the best leader either, but IBM's problems started long before she was in control. Palmisano was good at fooling the shareholders causing the price to go up, but that can only go on so long before a critical mass figures out the problem.
IBM hasn't really had a good CEO since Gerstner. Palmisano just rode the inertia, and knew when to leave to look good.
I didn't say reject processes, I said they shouldn't dominate the thinking of those adhering to them.
The problem is that in practice, many Agile teams I've encountered experience scenarios where they *will not* proceed even if they overwhelmingly know it's the right thing to do because it hasn't worked out in their processess and tooling.
Now let's hypothetically assume that the warming trend would happen regardless. Why should that be a blank check to exacerbate the problem? Our interest is unambiguously in *not* allowing warming to happen, natural or otherwise.
We know that some things we do can be making things worse, and some things we can do that improve things. Rather than arguing about whether or not the warming is our fault or not, we should be focused on doing what we can to slow or stop it.
It's amazing when I see people say 'but it was much warmer millions of years ago, so this is just natural'. Giving that our species was not alive at the time, I fail to see how that argument works.
I guess it's the erroneous position of 'save the Earth'. We really mean 'save ourselves' because the Earth is going to be fine and probably life on Earth will be able to continue, we just might not be able to live in it.
Not if they want new employees to hit the ground running.
The ramp-up contributed by lack of familiarity with your selected tools should be so small as to not be noticeable in the presumably much larger ramp-up associated with them familiarizing themselves with your specific team and work. If you are actually needing sophisticated project management tools, then your work is not trivial and there is *no* way to hit the ground running, and the *least* of your worries should be whether or not they are able to figure out your selected tools. If it *is* a significant challenge and that is expected, then there's something wrong with your selection of tooling or how you've approached customizing it.
What if it isn't? What if they don't want to pay you to figure it out?
If the candidate has a noticeable challenge with code management/review/continuous integration/issue tracking against the backdrop of ramping up with the tools, then they won't be very good at doing the actual work. If the work is simple, then the infrastructure should be simple. If the infrastructure must be complex than the work must be appropriately more complex and everyone should know what the right ramp up time is for their projects. If a company is unwilling to pay for an employees to go through an appropriate ramp up period, then they won't be able to find any employee.
And they just sold out for $425 million.
I don't understand how that makes any sense whatsoever in context. I was not disparaging either company in my commentary or use of their products, just that if an employer does choose a particular tool-set for managing their work, they shouldn't be terribly afraid of a candidate that didn't do it the exact same way in their previous experience.
they succeeded so their method is definitely workable.
Again, I never said Trello was bad, just that an employer fixating on specific software experience rather than broader experience and problem solving skills is going to have worse candidates. A candidate that has not used Atlassian or Trello is not necessarily bad if your company rolls that way. A candidate that would be scared to use Atlassian or Trello would similarly be bad.
The simplest counterargument to your entire line of reasoning is this: If they have access to a pool containing hundreds of competent candidates
As someone currently trying to fill positions, there simply isn't at a given time *that* many relevant candidates at a given time, at least for complex software development if you've filtered the pool based on more critical criteria. It's a waste of time to be doing resume filtering based on your specific code and project management software, when there are always *so* much better criteria to use.
If an employer gets hung up on whether a developer has used Atlassian product before, then they are crazy. The learning curve of these systems should be trivial. If the applicant at least seems comfortable with the principles of how you do things, knowledge of the tools should be easy.
I could see getting a bit nervous if they have not used git, but even then if they'd used any version control software, I wouldn't be too bothered.
Ideally you wouldn't even get *too* hung up on whether they have experience with the same programming language, as long as they are competent at programming language choice doesn't matter.
Of course if they are scared off by the prospect of dealing with a new tool or language, *that* is a sign of trouble. I find it valuable to fish for technology a candidate is not familiar with and see how they react to the prospect of having to deal with it, even if that technology would not be part of the actual job.
Maybe in the hands of a very dedicated team customizing bugzilla, it can be ok. I have not yet seen it happen (including Mozilla themselves, as well as RedHat).
However, out of the box redmine worked pretty well. With less than a day of learning, we could implement a new workflow in a few minutes. It's such an underrated piece of software.
On top of that, the whole origin of Agile goes explicitly *against* what I hear from a lot of parties claiming to convert some process to agile.
"Individuals and interactions over processes and tools"
Yeah, that's not at all a profitable thing, so now Agile advocates mandate certain specific ways and tools. The fact people even say 'The Agile Process' seems to run counter to the very first sentence that started off the whole 'movement'.
This whole evolution from reasonable call for sanity to insane consultancy industry has produced crazy stuff like http://programming-motherfucke..., which if not for the fun and offensive choice of phrasing I could imagine becoming the new consulting fad in a decade.
It's a good deal because the customer will have to buy another one after 3 or 4 years due to burn in or the blue wearing out. It's a great deal for the vendor.
(Continues to lament that we can't have both true black and a display technology that won't burn in or wear out quickly).
A good rule of thumb is if they mention they use Agile within 5 seconds of starting an interview, or in general devote more than 5 or 6 words to explain that they use Agile, then they probably are not doing it truly right. They can speak about the tooling they use with more words, but if they feel obsessed with explicitly wrapping every concept back to the word 'Agile' rather than leaving it implied then it's probably a good sign to run away.
I'd much rather see something like redmine raised as an example. Bugzilla is a terrible ticketing system. If JIRA is worse than that, that just seems like an extremely hellish proposition.
First they talk people into getting rid of Git then shove Bitbucket down your throat.
I assume you are talking about something else than getting rid of Git, since bitbucket is a git based solution. I prefer GitLab over bitbucket for on-prem, and github for community based work (networking effect and all).
What we have found to work best for us has been: redmine - bugs/feature/project tracking gitlab - repository and code review (I know, there are better code review systems out there, but we don't have fancy needs) jenkins for CI - again nothing particularly sexy there to really feel strongly about one way or another mattermost - team chat for larger teams that warrant that - benefits of slack without the drawbacks
GitLab does a decent job of having a private git repository and code review with ability to have continuous integration.
I really don't like the thought of one company (Atlassian) being synonymous with 'Agile'. You don't have to use their tools to be doing Agile right, and in general you shouldn't be so obsessed with 'Agile' and lose sight of what your actual objective is.
We have used redmine in the same capacity for requirements, project and issue tracking. It's not as shiny and almost no one knows about it, but it's got a surprisingly powerful project management and ticketing system. Unfortunately it's code repository integration is rather weak, but it can be hooked into Gitlab to try to have the best of both (repository management of gitlab with the project tracking of redmine).
In my experience if I hear 'the Agile' then almost certainly the process actually in use is not Agile, but the company in question did give some consultant a lot of money to let them tell themselves that. Especially if they go on and on about their Agile process sometimes even more than they want to talk about what they actually *do*.
Real agile shops tend to not really think much about it. They focus on what they do, and they may use 'Agile' process and such, but it's never something that dominates in their mind. This actually makes sense because Agile came about as a rejection of a process-obsessed software development culture where teams would get so tangled up in formal processes that a lot of work was more process overhead than work, so while a process needs to be in place, it shouldn't loom large in the minds of those following it.
Now Agile is a buzzword milked for consultancy and certification fees. Atlassian gets some of my disdain for contributing to that (I've heard so many people say you can't possibly be doing Agile if you aren't using JIRA for example), but based on my experience at least their software isn't bad (though perhaps not worth the price compared to free alternatives), so they at least contribute something compared to other businesses invoking 'Agile' for financial gain.
This is the fate of *anything* that becomes hyped in the world dealing with something like software/project management, it will be diluted and perverted and become indicative of very little.
Well, it's not just google. That attitude is infecting a lot of the industry. Business leaders have figured out that short term prospects can be very good based on the '80%', and by the time the jig is up, they've moved on to another fly by night project exploiting that short term benefit.
This is not the first time, the dot com bubble was also built largely on this sort of behavior. Companies that prioritize ability to provide long term support take a backseat to the new blood that has nothing to lose and churn out very impressive, impossible to support concepts.
Of course another reality is that all this stuff is extremely important for building an ecosystem of independent parties to collaborate, but the bread and butter of Google, Facebook, Twitter, LinkedIn, and others is a monolithic web application. Changing the rug out from under yourself when you have close business and personal relationships in your team can be the most effective way forward in that scenario. Then they carry over their internal sensibilities into the outside world and things are less than happy, but it's hard to ignore the brand strength and how impressive the short term offering can be sometimes.
A lot of us are less worried about what our *own* appliances are doing and how they are set up than they are worried about how *other* appliances are set up. Electronics mindlessly tossing in connectivity makes for potentially larger and larger botnets to wreak havoc on the rest of us.
Of course, LG determining that computing with internet connectivity is now so cheap that there's no point in ever omitting it is rather a symptom rather than a cause (if they did omit on principle, then the equally cheap internet connected competitors would just outsell them).
The reality is that pulling in dependencies has gotten perhaps *too* easy to the point of depending on external service or software in such a way that the rug could be yanked out from under you in a way that could have been easily avoided.
It's not really *that* new, but people are quick to look for depedencies that really aren't needed. They hear some protocol or some RFC and immediately jump to searching for a library, when if they read the protocol or RFC they would realize it's a trivial little thing that could be handled with a little function. I know there's a real risk of reinventing the wheel here and there's a healthy balance to be struck. It's not good to be so desperate that you'll start using some completely unknown highly dubious dependency because it's all you can find when you could roll your own.
What is relatively new: it's now utterly trivial to point your end-user to get dependencies from online, pypi, gems, npm, ppa, or (rarely) copr. Of course the owner of that dependency could have any unknown philosophy for maintaining and testing, and can push broken updates, incompatible updates, or change their mind and take their ball and go home for whatever reason (http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/). In my mind, it's a good venue for projects to deliver to peer developers and to users (in the case of ppa or copr when you reference *no* other ppa or copr content) but as soon as a developer is referencing other developer content to their users, it's a recipe for disaster.
Of course these services are a whole new mess, since they *cannot* avoid the distribution mistake referenced above.
I meant that any remotely laptop sized panel would be inadequate. Having three of them would not be an adequate substitute for multi-monitor on the desktop.
I just think this is one 'middle ground' that doesn't really exist.
Slashdot Mirror
Once upon a time, 'powerful' computers were a precious resource that could not be dedicated to a single person, and so these impossibly dumb terminals were all people were allowed.
Then as things advanced, that model became obsolete, as devices much more powerful than the old powerful computers were so cheap, it just made sense to have everyone use dedicated computing devices, empowering the users and enabling a thriving home computer market of self-empowered users.
On the networking front, things started with BBSes and more relevant to most, walled garden environments like AOL and Prodigy. The scope of what they could provide was limited by network limitations, but to the extent communications and information flowed, it was controlled by your service provider with an iron fist. You *had* to pay AOL money if you wanted anyone to be able to find your data by keywords online, as an example.
Then as networking advanced, federated technologies like WWW and IRC prevailed, and suddenly the barriers of competition were reduced again and people could communicate and change who got their money and attention on a whim without repercussions. The late 90s were defined by standards and federated approaches displacing proprietary and isolated technologies. It represented a time where companies that had locked down their corners of the market had their customer base opened up to competition. Without this, Google, Twitter, Facebook, LinkedIn, and so forth never would have been able to start, it would have just been all-AOL.
In this century, we've seen a select few corporate interests get back much of the control. Google has become the de facto gatekeeper to the web, software vendors now don't need to let users download or can require their software to checkin and implement a 'rental-only' model for software, and applications that were once federated or at least could be instantiated by many are dominated instead by locked-in solutions (e.g. Slack is so much better than IRC, but is controlled by a single corporate interest, though MatterMost is pretty good at least...). Every little voice recognition clip is uploaded to remote servers for processing despite the fact the edge devices are orders of magnitude more powerful than systems that were doing voice dictation 20 years ago. We have been trained to treat multiprocessor multi-gigahertz devices with gigabytes of ram as dumb terminals not appropriate for any remotely serious task.
No, the old ways aren't better from a UI perspective or an experience perspective, but make no mistake that the power dynamic change that has come with it has downsides, and that's not so much the fault of the technology, just the usual power dynamic of human nature reasserting itself after a brief period where things were taken by surprise.
If I had to bet, I'd bet on browser embedded in the client rather than a remote video. You can do almost anything you could need in a mobile device using a web browser with javascript.
A remote video solution would be utterly terrible (it's not even seemless on local high speed networks, over mobile networks it's atrocious no matter who the vendor is).
It's called 'Chrome' (as others have pointed out).
What Google *specifically* promised was run an application without installing under android. I presume we are talking about a read chunks of the application on demand rather than requiring the whole thing to download in advance, so the application would think the device just has *really* slow storage for accessing the application payload.
However it could be as simple as changing the UI to make the download be invisible to the user (which is how web apps work, they get downloaded and cached when possible on load rather than have a distinct 'install' phase) and the 'feature' only working with small apps where that's reasonably possible.
Eh, we know what he meant, a modern web browser with javascript effectively being a runtime environment to produce applications that act pretty much exactly like a desktop application if desired. It's of course erroneous to say 'apps you don't download', since the apps are downloaded and cached, it just doesn't make a production out of it. Which is of course going to be the case for WeChat or Google or *anything* for that matter (after all a processor cannot run code that it can't read).
I know that if you described something like this to the original www team at the time they'd wonder at how their original vision of 'gopher++' turned into *this*.
They should have renamed to 'goggles'. What? It's for the eyes, to search you know....
A lot of people make the mistake of judging Chinese output by the quality of what is done there as paid for by western companies. In effect, many western companies are pretty much getting scammed by getting the worst of the worst in China, and the western company doesn't realize they are getting the bottom of the barrel because they also buy into the 'China just isn't that good' story.
Meanwhile native Chinese companies understand the lay of the land and can be quite competitive by leaving the bottom of the barrel to the foreign companies to deal with.
It's the biggest pitfall of offshoring to any nation that the leadership is not intimately familiar with. If the business leadership has stereotypes about a popular offshoring destinations, they can get pretty much scammed into thinking they have average work for the region when they really get the rejects that aren't employable by the good local companies.
Of course, while Whiman has done no favors for HP, Apotheker gets the award for reversing the good fortune that had occurred under Hurd.
Hurd's tenure saw HP do exceedingly well, and Apotheker screwed over HP's core businesses in an effort to make it exactly another SAP.
To be fair to Romety, Palmisano was the one who set a crash course and 'roadmap 2015', got investors pumped and then promptly bailed probably knowing full well there was no realistic plan to deliver what he promised, but now it wouldn't be his fault. A lot of us were saying that Palmisano was nuts when he made that promise, then when he bailed we decided he was being personally very smart and was just setting up the next person to be the fall guy. Rometty stood by the pledge he made longer than she should have and the company was more and more damaged as a result, so she hasn't been the best leader either, but IBM's problems started long before she was in control. Palmisano was good at fooling the shareholders causing the price to go up, but that can only go on so long before a critical mass figures out the problem.
IBM hasn't really had a good CEO since Gerstner. Palmisano just rode the inertia, and knew when to leave to look good.
I didn't say reject processes, I said they shouldn't dominate the thinking of those adhering to them.
The problem is that in practice, many Agile teams I've encountered experience scenarios where they *will not* proceed even if they overwhelmingly know it's the right thing to do because it hasn't worked out in their processess and tooling.
Now let's hypothetically assume that the warming trend would happen regardless. Why should that be a blank check to exacerbate the problem? Our interest is unambiguously in *not* allowing warming to happen, natural or otherwise.
We know that some things we do can be making things worse, and some things we can do that improve things. Rather than arguing about whether or not the warming is our fault or not, we should be focused on doing what we can to slow or stop it.
It's amazing when I see people say 'but it was much warmer millions of years ago, so this is just natural'. Giving that our species was not alive at the time, I fail to see how that argument works.
I guess it's the erroneous position of 'save the Earth'. We really mean 'save ourselves' because the Earth is going to be fine and probably life on Earth will be able to continue, we just might not be able to live in it.
Not if they want new employees to hit the ground running.
The ramp-up contributed by lack of familiarity with your selected tools should be so small as to not be noticeable in the presumably much larger ramp-up associated with them familiarizing themselves with your specific team and work. If you are actually needing sophisticated project management tools, then your work is not trivial and there is *no* way to hit the ground running, and the *least* of your worries should be whether or not they are able to figure out your selected tools. If it *is* a significant challenge and that is expected, then there's something wrong with your selection of tooling or how you've approached customizing it.
What if it isn't? What if they don't want to pay you to figure it out?
If the candidate has a noticeable challenge with code management/review/continuous integration/issue tracking against the backdrop of ramping up with the tools, then they won't be very good at doing the actual work. If the work is simple, then the infrastructure should be simple. If the infrastructure must be complex than the work must be appropriately more complex and everyone should know what the right ramp up time is for their projects. If a company is unwilling to pay for an employees to go through an appropriate ramp up period, then they won't be able to find any employee.
And they just sold out for $425 million.
I don't understand how that makes any sense whatsoever in context. I was not disparaging either company in my commentary or use of their products, just that if an employer does choose a particular tool-set for managing their work, they shouldn't be terribly afraid of a candidate that didn't do it the exact same way in their previous experience.
they succeeded so their method is definitely workable.
Again, I never said Trello was bad, just that an employer fixating on specific software experience rather than broader experience and problem solving skills is going to have worse candidates. A candidate that has not used Atlassian or Trello is not necessarily bad if your company rolls that way. A candidate that would be scared to use Atlassian or Trello would similarly be bad.
The simplest counterargument to your entire line of reasoning is this: If they have access to a pool containing hundreds of competent candidates
As someone currently trying to fill positions, there simply isn't at a given time *that* many relevant candidates at a given time, at least for complex software development if you've filtered the pool based on more critical criteria. It's a waste of time to be doing resume filtering based on your specific code and project management software, when there are always *so* much better criteria to use.
If an employer gets hung up on whether a developer has used Atlassian product before, then they are crazy. The learning curve of these systems should be trivial. If the applicant at least seems comfortable with the principles of how you do things, knowledge of the tools should be easy.
I could see getting a bit nervous if they have not used git, but even then if they'd used any version control software, I wouldn't be too bothered.
Ideally you wouldn't even get *too* hung up on whether they have experience with the same programming language, as long as they are competent at programming language choice doesn't matter.
Of course if they are scared off by the prospect of dealing with a new tool or language, *that* is a sign of trouble. I find it valuable to fish for technology a candidate is not familiar with and see how they react to the prospect of having to deal with it, even if that technology would not be part of the actual job.
Maybe in the hands of a very dedicated team customizing bugzilla, it can be ok. I have not yet seen it happen (including Mozilla themselves, as well as RedHat).
However, out of the box redmine worked pretty well. With less than a day of learning, we could implement a new workflow in a few minutes. It's such an underrated piece of software.
On top of that, the whole origin of Agile goes explicitly *against* what I hear from a lot of parties claiming to convert some process to agile.
"Individuals and interactions over processes and tools"
Yeah, that's not at all a profitable thing, so now Agile advocates mandate certain specific ways and tools. The fact people even say 'The Agile Process' seems to run counter to the very first sentence that started off the whole 'movement'.
This whole evolution from reasonable call for sanity to insane consultancy industry has produced crazy stuff like http://programming-motherfucke..., which if not for the fun and offensive choice of phrasing I could imagine becoming the new consulting fad in a decade.
It's a good deal because the customer will have to buy another one after 3 or 4 years due to burn in or the blue wearing out. It's a great deal for the vendor.
(Continues to lament that we can't have both true black and a display technology that won't burn in or wear out quickly).
A good rule of thumb is if they mention they use Agile within 5 seconds of starting an interview, or in general devote more than 5 or 6 words to explain that they use Agile, then they probably are not doing it truly right. They can speak about the tooling they use with more words, but if they feel obsessed with explicitly wrapping every concept back to the word 'Agile' rather than leaving it implied then it's probably a good sign to run away.
much less productive than Bugzilla
I'd much rather see something like redmine raised as an example. Bugzilla is a terrible ticketing system. If JIRA is worse than that, that just seems like an extremely hellish proposition.
First they talk people into getting rid of Git then shove Bitbucket down your throat.
I assume you are talking about something else than getting rid of Git, since bitbucket is a git based solution. I prefer GitLab over bitbucket for on-prem, and github for community based work (networking effect and all).
What we have found to work best for us has been:
redmine - bugs/feature/project tracking
gitlab - repository and code review (I know, there are better code review systems out there, but we don't have fancy needs)
jenkins for CI - again nothing particularly sexy there to really feel strongly about one way or another
mattermost - team chat for larger teams that warrant that - benefits of slack without the drawbacks
GitLab does a decent job of having a private git repository and code review with ability to have continuous integration.
I really don't like the thought of one company (Atlassian) being synonymous with 'Agile'. You don't have to use their tools to be doing Agile right, and in general you shouldn't be so obsessed with 'Agile' and lose sight of what your actual objective is.
We have used redmine in the same capacity for requirements, project and issue tracking. It's not as shiny and almost no one knows about it, but it's got a surprisingly powerful project management and ticketing system. Unfortunately it's code repository integration is rather weak, but it can be hooked into Gitlab to try to have the best of both (repository management of gitlab with the project tracking of redmine).
In my experience if I hear 'the Agile' then almost certainly the process actually in use is not Agile, but the company in question did give some consultant a lot of money to let them tell themselves that. Especially if they go on and on about their Agile process sometimes even more than they want to talk about what they actually *do*.
Real agile shops tend to not really think much about it. They focus on what they do, and they may use 'Agile' process and such, but it's never something that dominates in their mind. This actually makes sense because Agile came about as a rejection of a process-obsessed software development culture where teams would get so tangled up in formal processes that a lot of work was more process overhead than work, so while a process needs to be in place, it shouldn't loom large in the minds of those following it.
Now Agile is a buzzword milked for consultancy and certification fees. Atlassian gets some of my disdain for contributing to that (I've heard so many people say you can't possibly be doing Agile if you aren't using JIRA for example), but based on my experience at least their software isn't bad (though perhaps not worth the price compared to free alternatives), so they at least contribute something compared to other businesses invoking 'Agile' for financial gain.
This is the fate of *anything* that becomes hyped in the world dealing with something like software/project management, it will be diluted and perverted and become indicative of very little.
Well, it's not just google. That attitude is infecting a lot of the industry. Business leaders have figured out that short term prospects can be very good based on the '80%', and by the time the jig is up, they've moved on to another fly by night project exploiting that short term benefit.
This is not the first time, the dot com bubble was also built largely on this sort of behavior. Companies that prioritize ability to provide long term support take a backseat to the new blood that has nothing to lose and churn out very impressive, impossible to support concepts.
Of course another reality is that all this stuff is extremely important for building an ecosystem of independent parties to collaborate, but the bread and butter of Google, Facebook, Twitter, LinkedIn, and others is a monolithic web application. Changing the rug out from under yourself when you have close business and personal relationships in your team can be the most effective way forward in that scenario. Then they carry over their internal sensibilities into the outside world and things are less than happy, but it's hard to ignore the brand strength and how impressive the short term offering can be sometimes.
A lot of us are less worried about what our *own* appliances are doing and how they are set up than they are worried about how *other* appliances are set up. Electronics mindlessly tossing in connectivity makes for potentially larger and larger botnets to wreak havoc on the rest of us.
Of course, LG determining that computing with internet connectivity is now so cheap that there's no point in ever omitting it is rather a symptom rather than a cause (if they did omit on principle, then the equally cheap internet connected competitors would just outsell them).
Well, it really depends on *what* you are doing.
The reality is that pulling in dependencies has gotten perhaps *too* easy to the point of depending on external service or software in such a way that the rug could be yanked out from under you in a way that could have been easily avoided.
It's not really *that* new, but people are quick to look for depedencies that really aren't needed. They hear some protocol or some RFC and immediately jump to searching for a library, when if they read the protocol or RFC they would realize it's a trivial little thing that could be handled with a little function. I know there's a real risk of reinventing the wheel here and there's a healthy balance to be struck. It's not good to be so desperate that you'll start using some completely unknown highly dubious dependency because it's all you can find when you could roll your own.
What is relatively new: it's now utterly trivial to point your end-user to get dependencies from online, pypi, gems, npm, ppa, or (rarely) copr. Of course the owner of that dependency could have any unknown philosophy for maintaining and testing, and can push broken updates, incompatible updates, or change their mind and take their ball and go home for whatever reason (http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/). In my mind, it's a good venue for projects to deliver to peer developers and to users (in the case of ppa or copr when you reference *no* other ppa or copr content) but as soon as a developer is referencing other developer content to their users, it's a recipe for disaster.
Of course these services are a whole new mess, since they *cannot* avoid the distribution mistake referenced above.
While I think a lot of the looks are improved compared to the rather ugly steps in Windows 8/10, there is a massive amount of wasted space.
I meant that any remotely laptop sized panel would be inadequate. Having three of them would not be an adequate substitute for multi-monitor on the desktop.
I just think this is one 'middle ground' that doesn't really exist.