In our case it's actually the scala/play layer that's connecting to all the disparate systems. Node is only connecting to that as a REST API.

Well this is embarrassing. The first pull request I open went to an online continuous integration website (which I just learned about right when I did it). After 5 minutes, it promptly failed

You are not alone.

Also this is for my first contribution on github. So thankfully it's not a real job

I'm about to finally start contributing on github as well Barin! (Shoulda done it longggggg time ago)

finals week

need above a 50 on my c++ final to get an A in the class

and wife is coming down with the flu, so my brain will probably be fried when I take it

So I found out that it's unable to compile the unit tests with cmake-make. I am getting an undefined linker error for a file I included.

However for the main program I am able to cmake-make just fine.

How do you like Play? I've been meaning to stop being lazy and write a project in it at some point but I haven't managed it.

Can't speak for suzzer but it feels very much like ASP.NET MVC - in fact, Play and ASP.NET MVC are more similar to each other than any pair of unrelated frameworks I've ever used. Routing is the biggest difference between the two, though in practice, tooling and ecosystem differences will make them seem more different than they actually are. For writing JSON APIs as opposed to server-side apps, language and runtime differences usually dominate over framework differences. I find Scala quite a bit nicer to work with than C# but I'm a FP nut, so YMMV.

I haven't done anything on the Play side yet.

ASP.NET huh? *shiver*

I suppose I haven't done anything with ASP since the halcyon days of yore, before .NET, but still, I uh, I'm scared now

So it goes like:

1. ASP
2. ASP.NET Webforms
3. ASP.NET MVC & Web API

1, 2, and 3 have almost nothing to do with one another except they came from Microsoft and therefore have shared branding and shared code by way of IIS and other libraries. Their equivalents in the Java world are:

1. JSP
2. JSF
3. Play Framework / Spring Roo

Their equivalents outside of enterprise would be:

1. Early LAMP where P = Perl with CGI.pm or PHP.
2. PRADO
3. Rails/Django

fair enough

so, for you working people who need to learn a new tech or language, how does it work? Do you just spend evenings pouring over books and blogs? Do you learn at work and get paid?

What's the normal expectation?

Usually learn at work and get paid for me. At least after the first few.

Yeah, usually at work for me - and always while working on something real. Learn by doing and all that jazz.

again I just don't get how you people get this stuff scheduled in agile. Whenever I do I get essentially told to get back to work on real development. I'm even the scrummaster now =/

It's easy. The story isn't learning the technology. The stories are what you want to get done with the technology. If you don't know the technology very well start with simple stories and estimate them longer.

But if you can't come up with valuable things you want to use a technology for then of course it's hard to convince people to let you learn it.

another common reason is that you're making an up front investment in the technology that will be a short term loss compared with continuing your "real development" as usual, but will more than pay for itself over X weeks since future development and maintenance will be faster compared with what you're doing now.

more simply: you're investing in the future.

this promise doesn't always pan out, though, and business managers are more skeptical than developers, who have their own reasons (fun, novelty, resume padding) for learning new technology. you just have to convince them that it really will pay off in measurable business improvements.

I'm pretty skeptical of anything that won't show short term benefits.

If you're making a major infrastructural change that won't show short term benefits there better be a lot of really obvious pain to justify that.

I recall suzzer talking about how they were paying Oracle around $60mil / year, so I suppose one win for open source is the price.

ofc, but isn't a lot of really obvious pain almost the norm most places?

I only heard the phrase technical debt the other day. That will be a super useful wikipedia article in convincing my boss that technical reforms are really necessary on some of our products.

Programming is unfortunately a kind of perfect storm of an industry where 1) management frequently have no idea whether any kind of technical upgrading or consolidation has to be done and 2) programmers are frequently the kind of people who are convinced that it's essential that the company's infrastructure be upgraded to SuperAwesomeFramework 4.0. I think I'm less rewrite/upgrade happy than most programmers but I still have to fight with management sometimes to get stuff done.

I guess, yeah. Although I think the vast majority of 'obvious pain' that people complain about usually falls into one of:

1. Not 'profitable' to fix (in whatever metric of profitability you want to use).
1b. Not 'profitable' to fix, and not felt by non-developers.
2. Not actually that painful compared to other realistic options.
3. Not related to technologies.

So what I"m talking about is more of things where you can make a very clear case to all shareholders that what you want to do will provide overall value.

And maybe another way of saying it, is that 'really obvious pain' is a very relative concept. If you're at a complete ****-show of a company with no testing and really old technology it probably doesn't make sense to try to migrate your Data Warehouse from Oracle to Redshift. Even if that will save a bunch of money it probably isn't the biggest problem at that point.

I've had (and seen others have) good luck with the approach of trying new technologies with new products / new major features. And if those technologies prove themselves you then have solid data to make the case that other products should then be updated too.