|
|
|
|
|
|
|
|
|
|
|
|
|
Scott Selikoff wrote:
Al Razor wrote:Hi Scott and Jeanne,
Could you please answer a couple of questions:
1. From your observations, which topic do you think is the hardest for people who upgrade from Java SE 6 OCP but have experience with Java 8?
2. Do you think that Java OCP certificates still have the same value as they had 5 years ago?
1. Streams and lambdas, since are they largest change to Java since generics. That said, there is a huge advantage in your every day coding if you understand them well. Some of the other topics like Concurrency, Annotations, NIO.2, JDBC, etc may also be difficult you've never used them so it depends on how broad your knowledge is. One of the values of studying for the cert, tho, is to broaden your knowledge.
2. I think they are more important than ever given how complex Java has grown over the years. Back in the 1.4 Java was relatively simple by comparison so it didn't take a lot of knowledge to know the language well. There are so many new (and exciting) things like Streams, local type inference, annotations, etc, that being a well-rounded Java developer is more important than ever.
Dylan Shields wrote:Hey Al,
This conversation comes up all the time!
My opinion here is that generally you should still be securing internal applications, even if they're only accessible within a private network. People make mistakes all the time in configuring networks, and it can be pretty easy to mess up a firewall rule, or place an application in the wrong subnet, or add an internet gateway or peering link in the wrong place. And then your applications are exposed. Having some basic authentication/authorization checks in your internal applications can give you a second level of defense in the case that your application is inadvertently exposed, or an attacker finds a way into your network.
Additionally, if you have multiple applications running in the same VPC, there's a blast radius issue. If one application is compromised, an attacker could leverage the position of that application on the network to compromise the rest of the unsecured applications.
There are also potential insider threat concerns, though that depends on the nature of the applications and what kind of access insiders have.
Dylan
Junilu Lacar wrote:
Al Razor wrote:I work in an enterprise like that and this company moved to cloud (AWS) a few years ago. I've seen how this change affected more than just technical side of things. This is the reason why I mentioned it in my original message.
Maybe mentioning that then could have brought us to this point much earlier. Were the effects of the change for the better or worse? What were some of those effects, specifically?
Junilu Lacar wrote:
Al Razor wrote:Quite surprising to see that book almost doesn't cover it.
That's quite the understatement considering the single occurrence of the word "cloud" in the book is buried in that one paragraph I quoted.
I think this quote from https://www.theguardian.com/deloitte-public-sector-in-a-digital-world/2020/apr/06/the-switch-to-cloud-how-public-services-are-becoming-more-agile-and-innovative nicely outlines some of the points:
And therein lies the difference, I think, in the idea of agility that Bob writes about in the book and the kind of agility you seem to be thinking about. But let's wait for Bob to chime in on this, maybe I've got it all wrong, which wouldn't be at all surprising.
Junilu Lacar wrote:
In an enterprise where thousands (yes, that many) of different applications are deployed on a worldwide network of servers in various data centers, even upgrading from one version of a server platform to the a new version can be quite the undertaking. In one company I worked for, it would take at least a year of preparation and coordination. In one company I've consulted for, they're still a ways away in their now years-long effort to move off of their mainframe. There are a lot of things getting in their way, not the least of which is the huge amount of technical debt (translated, per Ward Cunningham's definition, to "lack of understanding") in their current mainframe systems.Al Razor wrote:You can't seriously compare moving to cloud to a change of one of the technologies at the very least because it affects your whole infrastructure.
Junilu Lacar wrote:I'm trying to say exactly what I asked: what's the connection between a change like going to the cloud and agility? Change is always there. Enterprises migrate to new technologies all the time, developers have to learn and adapt to new technologies all the time. How is moving to the cloud any different from say moving from DB2 to Oracle or from WAS to Nginx or Node, or Maven to Gradle, or technology stack X to technology stack Y. What do you see is so special about moving to the cloud?
I do have the book, by the way, and there's but one glancing mention of "cloud" in it in Chapter 7 "Software Craftsmanship" written by Sandro Mancuso, who was also a guest author here in the past.
Moving to the cloud not only saves time on purchasing and managing physical environments, it also opens up access to a suite of software on the internet as a service. It is far quicker to amend these to an organisation’s requirements, rather than have software written from scratch. “Traditional procurement and development processes could take several months, by which time an organisation’s needs may have moved on,” Appleton-Norman explains.
By moving to the cloud, Appleton-Norman has found that Deloitte’s public sector clients are able to embrace the pioneering attitude found at exciting startups where new ideas can be tested at breakneck speed.
“The cloud empowers companies to be part of the new wave of fail-fast, agile development,” she says. “With the cloud you can leverage the necessary storage capacity very quickly and there are usually software packages you can try out and adapt that already work on that platform. The real beauty for organisations is that the technology enables them to get pilot projects set up really quickly. If they work, it’s great, if they don’t, they can be shut down immediately with no extra expense incurred.”
Junilu Lacar wrote:@Al. what's the correlation between being agile and becoming cloud-oriented? I'm not seeing the connection...
Junilu Lacar wrote:I personally think that teams that have already moved from Java to Kotlin will stay in Kotlin until there's a compelling reason to switch back to Java. Maybe the same thing goes for teams that haven't made the switch to Kotlin yet (I mean that they'll stick with Java unless there's a compelling reason to go to Kotlin). I think teams that are doing Android development are more likely to make the switch to Kotlin though, since it has the backing from Google and the Android team. It's expressive and in many ways more enjoyable to code in than Java.
Junilu Lacar wrote:
Al Razor wrote:What do you think about Kotlin position when Java 14 becomes more available (OpenJDK released)?
Are you trying to imply that Kotlin would somehow become less relevant because of new features introduced in Java 14? Which specific features do you have in mind, if any?
I think that Kotlin will continue to evolve as more people use it. That path of evolution may be influenced by new additions and changes to the Java language and standard library but in my opinion, there's about as much pressure to change coming from Kotlin to Java, if not more. For example, Kotlin already supports multiline strings just as Groovy does whereas text blocks are still a preview mode feature in Java 14.
