This week we have a four page Java developer resume that needs help in a bunch of places. Again, I’ve redacted the content to protect the innocent.Summary
The resume started with a SUMMARY. If you read my resume articles, I greatly appreciate summaries.
Vaclav has been so extremely kind and helpful providing detailed and honest answers to all of my questions. It is now a great pleasure to share all of this with other persons interested in MPS.
If you are reading this blog regularly you know that I am interested in many things but language engineering is the topic closest to my heart. You could have also noticed that I am spending a lot of time working with MPS. If you are instead a new reader you may not know that MPS is an advanced Language Workbench based on projectional editors. In practice you can use it to create Domain Specific Languages with their editors and supporting tools.
Remote methods invocations are always been a hot topic for discussion in the Java world. What can Redisson framework have to offer to solve this task?
Usually remote method invocation implies the existence of a client side (invokes remote method) and server side (executes remote method).
It is that time of year again as TechCrunch reports on Mary Meeker’s 2016 Internet Trends Report. It is always an excellent analysis of the trends and should be required reading for everyone in our industry. TechCrunch also has the first report of the Salesforce purchase of Demandware. I don’t talk about acquisitions too often, but this is fairly big, about $2.8 Billion big. Lastly, XKCD has a great comic about map age, but it is an interesting view into world history as well. It is definitely something you should look at today.
As always, enjoy today’s items, and please participate in the discussions on these sites.
Welcome to another installment of This Week in Spring! It’s already June! Where. Does. The. Time. GO?? This week I’m in Chicago, IL, for the Chicago Coder Conference, Boston and New Hampshire for customer visits, London, England for Devoxx UK and Talin, Estonia for Geekout EE. If you’re around, be sure to say hi! Now then, we’ve got a lot to cover this week so let’s get to it!
A builder, in its most simple form, can be thought of as a hierarchically nested constructor which may take a closure as argument. Within the closure, further constructors may be called.
You, as implementer of a builder, decide what the constructors do, how they're called and which arguments they take. Normally, you will already have an existing data structure that you would like to construct or modify with builder syntax. These data structures are, for example, an XML document, a Swing UI or a JSON document. In these cases, Groovy provides builders out-of-the-box. Maybe you have a domain model, or a very specific document or message type that you would like to create and you want something more specialized. You need a domain specific language and the Groovy Builder syntax is just what you're looking for. I recently developed a builder for meta-data structures encoded in the Statistical Data and Metadata Exchange (SDMX) format.
We’ve covered various ways to debug scripts in JMeter, but now you have the ability to debug scripts step-by-step and receive updates in real time. Here’s how.Exit Complexity, Enter Simplicity
When I started to work with JMeter to create scripts, I was (as I’m sure we all do) feeling like debugging my scripts was way too cumbersome a process. By using the Debug Sampler and log() functions, it really felt like the old mainframe debugging days.
Containers based deployments are rapidly gaining popularity in the enterprise. One of the more popular container solutions is Docker.
Many view containers as virtual machines. They’re not. Well, kind of not. A container is a virtual walled environment for your application. It’s literally a ‘container’ inside the host OS. Thus your application works like it is in its own self-contained environment, but it’s actually sharing operating system resources of the host computer. Because of this, containers are more resource efficient than full blown virtual machines. You get more bang for your buck running a bare metal machine with a bunch of containers than you do running a bare metal machine with a bunch of VMs. This is why massive cloud computing companies running 10’s of thousands of servers are running containers. Google, Facebook, Netflix, Amazon are all big advocates of containers.
For the most part, Java is a very backwards compatible programming language. The advantage of this is that large systems can generally be upgraded to use newer versions of Java in a relatively easier fashion than would be possible if compatibility was broken on a larger scale. A primary disadvantage of this is that Java is stuck with some design decisions that have since been realized to be less optimal than desired, but must be left in place to maintain general backwards compatibility. Even with Java's relatively strong tie to backwards compatibility, there are differences in each major release of Java that can break Java-based applications when they are upgraded. These potential breaks that can occur, most commonly in "corner cases", are the subject of this post.
Sun Microsystems and Oracle have provided fairly detailed outlines of compatibility issues associated with Java upgrades. My point is not to cover every one of these issues in every one of the versions, but to instead highlight some key incompatibility issues introduced with each major release of Java that either personally impacted me or had more significant effect on others. Links at the bottom of this post are provided to the Sun/Oracle Java versions' compatibility documents for those seeking greater coverage.
Many programmers might try to find the value of x by passing all the array elements to the switch statement, but that is unnecessary.
In this quiz you don't need to calculate the return value of methodB, but you can pass the value, which is x/2 to the methodB first arg. You can find the result by calculating the following simple mathematical formulas.
I can't really have a Groovy retrospective without mentioning memory.
Over the last four years I have spent more time than any sane person should have to investigating memory leaks in production Groovy code. The dynamic nature of Groovy, and it's dynamic meta-programming presents different considerations for memory management compared to Java, simply because perm gen is no longer a fixed size. Java has a fixed number of classes that would normally be loaded into memory (hot-reloading in long living containers aside), whereas Groovy can easily change or create new classes on the fly. As a result, permgen GC is not as sophisticated (pre moving permgen to the normal heap anyway) and largely in Java if you experienced an Out-Of-Memory permgen exception then you would just increase your permgen size to support the required number of classes being loaded by the application.
In Part 1 of this series we looked at how to get Swift up and running. In this part, we will look the Differences between Java and Swift at a basic language level by creating the Swift classes and comparing them to Java. For this article, we will go over the basics of class construction.Firstly, What's the Same?
Both languages are fundamentally statically typed class-based OO languages with single inheritance and interfaces. Furthermore, Swift includes the normal set of features that Java has including:
This post is one in a series about stuff formally trained programmers know–the rest of the series can be found here.Trees
This post will look at the mighty tree, which is more a pattern than a specific data structure. The reason to understand the pattern is that so many of the data structures we will look at in the future use it, and a good understanding of it provides a strong basis to work from.
As an optionally typed JVM based language, Groovy offers syntax and construct features that make development more efficient for a wide variety of tools and applications. The downside to Groovy is the runtime overhead for type checking and conversions, and certain other Groovy magic. For lower-level or frequently run code in certain cases it is best to write in plain Java but for most code Groovy has options to make your code run just as fast as Java.
The tips in this article are based on my experience writing and optimizing Moqui Framework which currently has around 40k lines of Groovy code. In plain Java the code would easily be double or triple the size, and generally far more complex as well. Moqui was originally written in 100% Groovy aside from the framework API which is mostly interfaces and is written in Java. There are huge benefits to using Groovy for a framework like Moqui as there is a lot of complex functionality to implement and Groovy helps the code stay simple and small. This makes the framework more flexible and easier to write, improve, and maintain. With the limited resources of an unfunded open-source project, these are critical factors, but apply even to large teams working with much larger codebases.
This post is one in a series about stuff formally trained programmers know – the rest of the series can be found here.Linked List
In the previous post on Array, we saw that all read operations are Θ(1), which is awesome. An important reality of programming is everything is a trade off, so when you get fast reads with Array adding items when you don't know the collection size is expensive.
Spring Data is pretty convenient and speeds up development, avoiding boilerplate code.
However, there are cases where annotation queries are not enough for the custom functionality you might want to achieve.
After Exercises in Kotlin: Part 3 - Functions we now take a look at control flows and actually doing some basic exercises.if/else
As mentioned earlier, if/else is not just a statement but can also be used as an operator (in lieu of the ternary ? : operator.
They can be more or less divided into those categories: