sghill

Up to what scale?

This works well for a couple dozen repos per team in my experience. It’s also my preferred way to work.

It doesn’t scale so well to hundreds of repos per team without significant tooling. At some point anything cross-cutting (build tool updates, library updates, etc) becomes hard to track. Repos are left behind as folks change teams and teams are reorg’d.

I’ve never worked in a monorepo, but I can see the appeal for large, atomic changes especially.

Definitely - we recently moved issue tracking to another system after 15+ years and found there were too many links to abandon, so we run a service that just redirects old URLs.

Breaking down work so it can be delivered incrementally is an underrated skill.

Simplifies communication about progress, builds confidence in ability to deliver, and makes it easier to avoid getting lost in rabbit holes. Especially in situations where there are lots of unknowns - unknown programming language, multiple tools to choose from, etc.

The old URLs aren’t kept around to redirect to the new location?

I’d like to see better centralized support generally from CI systems. Six months of steady migration and a custom DSL seems alarmingly common.

CI Wishlist:

* testable outside of CI

* required steps based on repo characteristics (ex: security scans)

* central step and workflow definitions

* controlled rollouts/rollbacks to simplify migrations

Guided runs in Nike Run Club are great for this. There are several coaches with different styles.

My favorite have been the Headspace mindful runs[1].

[1] https://www.headspace.com/meditation/running-meditation

This 2006 Stanford interview[1] with Kelleher sounds like taking ideas seriously was an important part of the culture. Tragic it was lost, as it always stuck out in my mind as an example of great leadership.

Southwest continues to encourage and applaud out-of-the-box thinking from everyone at the company, from flight attendants to top-level executives. He recalled one mechanic, for example, who submitted a sketch showing how to fit an extra seat onto the aircraft, in order to compensate for some over-wing exit seats lost due to a new federal air safety regulation.

In general, Kelleher said, if a Southwest employee submits an idea like that, he or she can expect to get an answer back within a week, and a lengthy explanation to boot. The point, he said, is “never spoil an idea, because when you spoil an idea, you ensure that you’ll never get another one from that person.”

[1] https://www.gsb.stanford.edu/insights/herb-kelleher-manage-g...

Does this new language save you that much over using a more generic and widly known language in the org?

This is a great question to ask. It’s worth extending beyond language to frameworks and libraries as well.

It’s important to optimize for the development experience across all the apps in a team. Especially once the excitement of using a new language is gone and there are bugs to fix.

I‘ve rewritten a few projects in a common language for the org. Each time the biggest benefit was how straightforward it became to work on. Problems you’ve found somewhere else become easy to spot (and search for). Writing another test is the same as the last project you had open. Anyone in the org can contribute with a minimal learning curve. This can be the difference in getting bugs fixed in a day or a month.

I've been a subscriber to NHL Gamecenter for two years. If you're very far from your home team, it can be a good deal.

In California, I can catch most of Detroit's games. In a major hockey market like Toronto, however, Detroit's games are often on TSN2 (think ESPN2), which means they are blacked out. Cable was the only way to see these, even though I would have guessed they were out of market.

It does sound like they were debating this for quite a while. Eric Lippert used to work on the C# compiler and published a blog post[1] immediately after the announcement:

    Since I always knew that open sourcing was a possibility I tried to write my portions of it as cleanly and clearly as possible; hopefully I succeeded.

I found the IntelliJ docs[1] handy for discovering predetermined variables like $END$ and $SELECTION$.

[1] http://www.jetbrains.com/idea/webhelp/live-templates.html

    When 90% of your "students" fail to complete the courses, you have an epic failure on your hands. MOOCs are not working.

Since graduating, I've enrolled in a handful of MOOCs. I've finished less than half of these courses, but they have satisfied my curiosity and have given me something new and different to learn. I most certainly would not have paid for the experience, but I feel I'm better off because of it. I'd say this is working and far from an epic failure.

I haven't used a serious app in production on OpenShift, but I have been playing around with a Java project recently. Assuming I get it to production, I'm going to stick with OpenShift. I think the blogs, forums, and docs are great.

I started out with gradle and embedded jetty, and found no out-of-the-box support. They did do a nice blog post on how to use gradle for builds[1]. Unfortunately, the blog uses gradle version 1.6 and that's the last gradle version that doesn't throw an exception while building[2].

Wanting things to be easier, I switched over to maven[1] and tomcat:

    OpenShift has supported Apache Maven as default build system for Java based projects since the first release.

I also really like that the environment configuration is stored in the codebase under the .openshift folder. This makes it very easy to, for example, develop locally against http but make all your traffic go through https on OpenShift. And the free piggyback ssl means https just works too.

[1] https://www.openshift.com/blogs/run-gradle-builds-on-openshi... [2]: http://issues.gradle.org/browse/GRADLE-2871

Flask and Rails have different focuses. I've used both and like them both quite a bit, but I've found there is often a clear winner depending on the task at hand.

Flask is a microframework that often fits within one file and is probably more comparable to Sinatra than Rails. I've only ever used it for setting up really small webservices and stubbing webservices. It could certainly scale up to larger apps, but it doesn't give you a lot of direction in how best to do so.

Rails is a full-stack framework. Out of the box it gives you everything from the view to the database and strong conventions for where to place classes as your app grows. In general, it's more often compared to Django.

Fair enough, I'd be reacting similarly I'm sure. I get that two years is too short, but how long do you expect a device like this to be supported? I think I recall three major updates for my original iPhone, but by the last update it was almost unusably slow.

Buying whatever Nexus is out there when I needed a new phone has always been a no-brainer. Not so anymore.

Interesting, I would not have expected so much importance to be placed on unspecified rolling updates.

My current phone is the only Nexus device I've ever had, but it was easily my best unlocked option at $250-300 US. I think that holds whether it's running 4.2 or the latest.

It's even possible to ride a driverless train in the US, and has been at least since the Detroit People Mover[1] opened in 1987.

[1] http://en.wikipedia.org/wiki/Detroit_People_Mover

I've always found it a lot more effective to sit down with someone and find the answer together, no matter how simple the question. If our technique works well, I've found they'll generally try it again the next time they have a question.

Unlike sending this link, figuring out things together doesn't leave teammates avoiding and dreading interactions with each other.

Hyperloop is all about passengers (something the rail industry has never cared out)

This is disingenuous. In the 150+ years of North American rail, many of America's most intricate architectural structures[1] are train stations, and they certainly weren't making that investment for freight. The dining car service was also typically a loss leader, designed with the sole purpose of attracting customers. Freight never complains, though, and ends up being much better to transport.

[1] http://www.nps.gov/stea/planyourvisit/lackawanna-station-100...

Yes. As an industry, we're not very good at recognizing the great things people do. We tend to focus solely on mistakes. It's not easy to admit failure, and if we want it to continue we should recognize the effort it takes.

There even exist situations (in the case of some positions) where you will be talking to a client of the company you're working for, effectively interviewing with the client, representing the company.

What positions would require you to prove the technical capability of your company at this level?

I've been working for a consultancy for a few years now. I can't recall a time when a client asked me to describe a closure or what I thought of !important. If I'm on a development team, the conversation with clients is generally about the time and effort required to implement something, or the options we have for delivering the functionality. If I'm pulled into a sales meeting, it's usually high-level architectural discussions.

Screw going to amazon et al to buy anything that changes as constantly as a car. or a cellphone.

You've made it clear you're a person who requires extensive test-driving. Amazon's cell phone business doesn't seem to be hurting. I've ordered my last two cell phones online sight-unseen. Same for recent laptops and a Nook. I'll take the uncertainty of holding a modern device over the sales staff.

I bet my right arm that you wouldn't ever buy a car from amazon if you couldn't test drive it at the local shoddy dealer.

The average car age in the US is now 11.4 years old[1]. My car will likely be 15 before I get another one. In VW's terms, that's at least three generations of progress. I'm buying a car for a decade, and none of the problems that come up in a decade will be revealed by a test drive.

Regardless, I merely agreed it wasn't currently an option and the parent may have a better experience with the internet sales department of his or her local dealerships.

[1] http://www.edmunds.com/car-news/average-age-of-cars-in-us-ju...

Why can't I go online and order the Jeep (or whatever else) I want and have it delivered or pick it up from a non-jackass?

True, you can't go to Amazon Cars or equivalent, but there are options. Have you tried the internet sales department? Edmund's called it "a valuable time- and money-saver."[1]

I wish the car manufacturers would get with it.

It's not like they haven't tried to make the buying experience more pleasant. Saturn was doing no-haggle pricing as early as 1990[2]. Scion is doing it today[3]. Gut feel is that the buying experience just isn't that important to most people with durable goods. The car is what brings us into dealerships, not the sales staff.

[1] http://www.edmunds.com/car-buying/how-to-get-an-internet-pri...

[2] https://en.wikipedia.org/wiki/Saturn_Corporation#1990.E2.80....

[3] http://www.scion.com/buy/pure_price/

It'd be interesting to see some research on that. Most of the plants I'm aware of aren't actually in Detroit proper, but the metro area.

A quick glance over the list of GM factories[1] shows just one assembly plant in the city. Chrysler has a bit more going on[2] in Detroit. Of course, this doesn't take into account all of the suppliers, which is a huge omission. In my experience growing up in the area, it wasn't so uncommon for someone to be working for a company whose sole customer was one of the Big Three.

[1] http://en.wikipedia.org/wiki/List_of_General_Motors_factorie...

[2] http://en.wikipedia.org/wiki/List_of_Chrysler_factories

> 37 Signals sells good to techies (and where techies are in charge of the order) but this particular product was specially geared towards non-techies, hence it would be really hard to make it work.

Based on what? I've always assumed they focused on non-techies as a target market, based on they way they sell simplicity and fewer features.

> Java never delivered on its promises

Which promises? Write-once, run-anywhere? My last Java project lasted 15 months, during which time we had developers working on Windows and Mac, with production running CentOS. I can't recall one platform-specific bug we encountered.

> The JVM cant even use 32GB of ram efficiently, and yet we can buy servers with 256GB of ram for 5K.

I've used Java for line-of-business web applications, which seems to fit within Java's wheelhouse. I'd be terrified to work on any purchase order system that required a 32GB heap to run. On that project referenced above, we maximized the use of cheap, larger servers the way many companies do now -- by running several smaller VMs on them that each contain one application.

> Java will not survive the next 10 years.

Which is saying that Android will not survive the next 10 years as well?

No, I can't say that I have. I just looked up Yahoo's Mail app on Google Play[1]. Unfortunately, the very first thing I see in the description adds to my perception of its quality and doesn't make me want to try the service:

> NOTE: We are aware some of you are having issues while attempting to view an email. To resolve this issue open settings > About Yahoo! Mail > Clear Cache. You should then be able to see your email messages post clearing your local cache. Sorry for the inconvenience.

The app does look to have mostly positive reviews, and that you're asking if I've tried it must mean they're taking a step in the right direction. I wonder if they've considered making it an IMAP client. Given that the built-in Android mail app leaves so much to be desired, I'd gladly try it for my work account, which may then slowly change my perception of Yahoo.

[1] https://play.google.com/store/apps/details?id=com.yahoo.mobi...

I think Yahoo has a lost generation[1] problem on its hands. Gmail in particular has made Yahoo's products look like Detroit's cars in the 70s and 80s.

Anecdotally, at some point in the 2000s, it became embarrassing to have a Yahoo email address. It invited in jokes of 'she must love spam!' or 'he must love getting his account hacked.' From here, it's a long and difficult road to recovery. From the 1991 article linked below, this quote sounds like it applies:

> "A lot of people would have trouble admitting to their peers that they bought an Oldsmobile even if they thought it was every bit as good as a Honda," said Chris Cedergren of J. D. Power & Associates, an automotive marketing company in Agoura Hills, Calif.

[1] http://www.nytimes.com/1991/04/09/business/detroit-strives-t...

> One advantage people don't often talk about with finance industry jobs is their incredibly lax moonlighting clauses.

Interesting. My first programming job was in a finance company who had a "we own everything you make, here or at home" policy. My manager said most finance companies would rather pay people more than have them working on things outside of work, which I took at face value. Knowing that was how I enjoy learning most, it was a big factor in my leaving.

Nice work! This looks quite useful. I'm definitely going to check it out. Big plus for having it on maven central.

I have a more general question -- where do I go to find more stuff like this? Do you also announce new versions somewhere with more of a focus on Android development?

I started doing more serious Android work about two months ago, and finding libraries has been more challenging than I expected. Through Stack Overflow comments, random conversations, and stumbling through things like Square's Github page I've managed to locate a handful of libraries that make development much better. It'd be great to know where this information lives, though.