Tim Cooke

That's an interesting approach Stephan, thanks. I'll have to discuss with the team and see what they think of it.

In general though I think you're right. The move to cloud computing has removed the need for a certain group of roles within an organisation, primarily relating the maintenance and security of the physical infrastructure and the maintenance and security of the operating system.

Although you might argue that the role has not been eliminated, rather simply moved to the cloud provider companies.

Cloud is just a fancy new name for somebody else's computer. You still need developers to build and maintain the application right?

I think you're conflating the term "developer" here which is causing some confusion, for me at least. To me a developer is the person who builds the application, who writes the code, who packages it up for deployment. I think the developer you are referring to is more of a system administration role rather than software developer.

You say "IT employees" but do you really mean the employees who look after the server infrastructure? Just because you don't physically own any server hardware doesn't negate the necessity to manage it. I see it as a change in skill set rather than the elimination of a role.

I have worked in large companies who own their own server hardware but have them located in data centres. From a practical point of view this is not so dissimilar to 'cloud' services. They're both server resources you don't have physical access to. You make some gains in not having to maintain the hardware and manage security updates, and you incur some costs in having to learn and navigate a 3rd party management console application to administer your resources.

I have a code workflow dilemma to resolve.

I'm a developer on a small team. Our current workflow for pushing code changes is to branch from the main 'dev' branch, do your work, then create a Pull Request for approval back into 'dev'. My development cadence us usually quite fast, I'll write tests, implement features, fix issues, refactor unpleasantness, all in a relatively short space of time, which is great but at the end of that I am inflicting an unmanageably large diff in the resultant PR that gets sent out for my team members to review. Because of this I usually end up having to sit down with them and walk through everything I've done. At the last review it was suggested / requested that I keep my PRs smaller to be easier to review. This is a fair enough comment.

The problem I have now is that I don't know how to adapt my workflow in order to produce smaller PRs and maintain a reasonable cadence of development. For example, my current bit of work started out with writing a new covering test for some existing functionality, and resolving a bug that I happened to find along the way. That seemed like a nice sized chunk for a PR code review. All is good. But..... it formed the basis for the next bit of work but the first PR has not been approved yet so I can't submit the second PR without it including the first also.

I hope this is making sense.

My question is: Have you any suggestions from experience about Pull Request size, frequency, scope, or anything else that works for you to maintain good development speed while making it easy for your colleagues to review your output?

As it happens I have recently implemented what Cornelia discusses for configuration files for the same reasons. Property files were being bundled up in the jar (it's a Java app) so the build was directly coupled to the configuration. Also we had sensitive configuration in plain text files, such as database credentials, email server credentials, Stripe payment gateway credentials (eek!).

I got the idea from Michael T Nygard's "Release it!" book, which is a terrifyingly excellent read and highly recommended. (I say terrifyingly excellent because it makes you realise how under prepared your application is for the production environment.)

We already use Amazon AWS for a bunch of other services so it was a natural fit to make use of their Parameter Store offering to keep our application configuration in. There was some code changes required to retrieve the properties and add them to the environment but it turned out to be not that hard because the AWS Java SDK does most of the heavy lifting for you.

You're welcome Muhammad, nice to see a 4 year old topic is still helping people

Spring stack traces are really cryptic are require some familiarity to decipher which is half the battle of working with Spring.

This week, we're delighted to have Hobson Lane, Hannes Hapke and Cole Howard helping to answer questions about the new book Natural Language Processing.


The promotion starts Tuesday, August 13th, 2019 and will end on Friday, August 16th, 2019

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, Manning.


Image from https://m.media-amazon.com

Please see the Book Promotion page to ensure your best chances at winning!

Posts in this welcome thread are not eligible for the drawing, and should be reserved for welcoming the author. Questions posted in this topic are subject to removal.

This week, we're delighted to have Cornelia Davis helping to answer questions about the new book Cloud Native Patterns.


The promotion starts Tuesday, August 13th, 2019 and will end on Friday, August 16th, 2019

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, Manning.


Image from https://m.media-amazon.com

Please see the Book Promotion page to ensure your best chances at winning!

Posts in this welcome thread are not eligible for the drawing, and should be reserved for welcoming the author. Questions posted in this topic are subject to removal.

Tim Cooke wrote:It's now on my list to be refactored out.

An update: Project Lombok has been removed from our codebase many weeks ago and nobody has missed it.

In my experience of working with very high performance systems, if you've got garbage problems then calling gc() is not even close to a solution.

First, a big thanks to Marco Behler for being here to promote Java Database Connections & Transactions (e-book only).

The winners are:

Dinkar Chaturvedi

genos raman

Salil Wadnerkar

Ray Jender

Please send your snail mail address to bookpromotion AT javaranch DOT com. To ensure the quickest response, please provide the following:

Your name (first and last - if your CodeRanch name is different, please include both your real name and Ranch name)
Email
Country (needed even if requesting an e-book)


Also, please include the following as the subject of your Email.

Promo Winner - Java Database Connections & Transactions (e-book only) - Tuesday, June 25th, 2019


Image from https://cdn.marcobehler.com

As noted in the Book Promotion Eligibility Requirements and Legal type stuff, the winners have 8 days to submit their information. Within 3 days of receipt of your email, we will reply to let you know we got it. If you don't hear back, the goat might have eaten your email. Please let us know by posting in the Ranch Office so we can check on it. Once you have received your copy please let us know by editing the Book Promotions Winners Page and updating the 'Status' column to say you have it.

Thanks and congrats to all the winners.

Wow! Amazing! Amazing! Amazing!

Congratulations Jeanne!

Liutauras, if I were in London right now I'd come round your house and hug you.

This is perfect! Thank you.

I did not have the right dependency. Now I do and it's working a treat! Thanks Dhiraj