Al Razor

Ranch Hand
+ Follow
since Mar 08, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
5
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Al Razor

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.



Thank you!
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?

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



Thank you, Dylan!
Then it will require some additional discussion.
Hi Dylan,

In the enterprise that I work in we have a number of services (applications) that are only accessible in VPC. A lot of these services don't have any security. Architects and team leads say that it is secure enough because no one from outside has access to these apps.
Do you agree with this statement or do you think that these apps should have at least basic internal security (for example, JWT or API key)?
Hi Stephen, Johan & James,

I have 2 questions for you:
1. I am looking to rewrite a file manager desktop application in Java with features like skinnable interface, file drag and drop, etc. Do you think JavaFX would be better suitable than Swing or could the amount of available libraries be a limiting factor?
2. If JavaFX is that great why big companies like, for example, JetBrains haven't switched over and are still using Swing for all their products? Is it only because of performance issues or are there some other potential issues?
1 year ago
Junilu, yeah, it seems to be more about classic agile, more about foundations. Thanks.

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?



Overall this was a positive change that provided a necessary performance boost, allowed the company to experiment more (to try some new projects), and also lead to decomposition of a few monoliths into smaller services. I think the main problem is that the initial investment is quite costly and takes a lot of time as it involves not just the moving of your software into the cloud but also requires you to ensure that your developers know this technology and can use it efficiently (for a lot of them clouds were a new technology).

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.



I was sarcastic about almost  

Yeah, this might be different kind of agility.

Junilu Lacar wrote:

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.

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.



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.

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.



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.
Quite surprising to see that book almost doesn't cover it.

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:

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...



Are you trying to say that there is no change involved when your company goes from having their own servers to using, for example, Amazon cloud solutions?
Because it does affect everything: it lowers infrastructure risks but requires you to change your CI/CD pipelines (take into consideration solutions used by your cloud provider), increases your dependency on DevOPs, forces your developers to keep their knowledge updated, etc.
Hello Robert,

What do you consider the most important changes over the past 10 years in the world of agile development?
How strongly has enterprises becoming cloud-oriented  affected it?

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.



Definitely there is no threat for Kotlin (at least from Java) in the Android territory.  
I guess Java will need to finalize these features and offer some notable extras with LTS release of Java 17.
1 year ago

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.



The most important one would be records but there are other like improved switch, pattern matching for instanceof, text blocks that you mention, etc. Yes, most of the are still in the preview (or second preview) but they should be implemented sometime reasonably soon.

I think it will make Kotlin less desirable for Java teams to switch to (I am mostly talking about enterprise backend development).
1 year ago
Hello Ian,

Which Java version would you recommend for deeper studying to Java 8 developer - 11 or 14?
What do you think about Kotlin position when Java 14 becomes more available (OpenJDK released)?
1 year ago
Thank you, Junilu and Sundar.
In my case the issue was that the team members were working on a few not related projects and developers would spend quite a lot of time every day listening to the information that isn't related to their project or their tasks. This was somewhat resolved by breaking a single large team into multiple smaller teams and each of these teams have a separate time segments for daily standups.