Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Azure DevOps UI provides an option to trigger multiple days or once a week. We know that many times we need to execute Azure DevOps pipeline triggers once a month, or twice a month, and this can be done using Cron Expressions in Azure DevOps.
Azure DevOps uses NCronTab to evaluate cron expressions, so advanced expressions are not fully supported by Azure DevOps. However, most of the expression is supported so it does the job.
Velocity in agile development measures the quantity of work a team can accomplish in a sprint. It can be measured in story points, hours or days. The higher the velocity of a team, the more features it delivers, the more value it brings to customers. Sprint velocity is a good measure in sprint project management to evaluate and estimate team productivity.
The measure of the velocity is based on multiple factors: the continuous integration (CI) process, the time to qualify the code changes, to test the regression, the security, the delivery, etc…
We’ve been on a bit of a redesign tear these last few months. I’m happy to unveil the latest one: a complete redesign of CodePen Settings!
Settings is one of the last remnants of Old School CodePen
. While I’ll miss the 2011 nostalgia, the new Settings page is a thing of beauty. Beyond the UI and UX we also ripped out another huge chunk of our Ruby on Rails stack and modernized to reusable React Components, expanded our GraphQL API, and refined our component library. The Settings codebase is a joy to work with!
Perhaps a redesign of the settings area of CodePen isn’t particularly exciting to you, dear user. Fair enough. But we really do hope that when you need to change settings, this new experience is much more snappy and clear. We revisited literally every single page and redesigned it for clarity and responsiveness. We’re particularly happy with how the billing information is presented. You should be able to easily see your current account status and billing history.
Now some fun! I love nothing more than before and after design unveilings, so buckle up y’all.
We flipped the tabbed navigation vertically. Which is the experience you’ll recognize from the rest of CodePen. We streamlined content where we could (For example, Customize is now within Profile, where it makes sense) but the tab names are almost exactly the same as before. It’s just far easier to absorb the beautifully laid out content from top to bottom. The permanent sidebar also makes it easier to remember where you are.
Before, you’d have to click that pesky Save button for your updates to take affect. No more! Thanks to elegantly laid out React Hooks, your changes automatically save. After a short grace period, of course.
An area that’s near and dear to my heart (only slightly kidding), we spent lots of time figuring out an improved UX for our entire billing system. We’ve got a few more phases of billing releases to go but this is a great start. For example, you no longer have to switch context to view your team’s billing information. We’ve got your personal billing tab up top with the rest of your personal settings. We created a new “Teams” section below to house your team billing tab alongside other team settings.
So many amazing changes, it’s hard to pick a favorite. But the team roster is high up there. If you’re the Team Owner, you’ll see a simple form below the roster for inviting new members by email.
I’ve saved possibly the best for last: editor settings. I know many of you will be using this settings pane the most, and hopefully its a delightful experience.
This was a massive effort from everybody on Team CodePen. It involved a ton of design, client and server side work and support desk emails. So it feels especially good to finally have new Settings on production, giving all y’all out there an improved CodePen. I promise, you don’t want to know how many support tickets were caused by confusion in the Settings area. Don’t mind us as we self-high-five. 
The post Settings: Redesigned! appeared first on CodePen Blog.
Happy New Year! As we enter the new decade, I decided it was time to write my now annual blog post giving my thoughts on what this year might hold for Java. I'll also look back on my predictions in the last post to see how accurate (or not) I was.
Obviously, the most significant thing this year will be the celebration of a whole quarter of a century since Java was launched. I plan to write a lengthy missive about the last 25 years of Java closer to the time.
In the post "JDK 14 Rampdown: Build 27," I summarized the numerous JDK 14-targeted features newly available with JDK 14 Early Access Build #27. There is already another JDK 14 Early Access Build available and this one [ Build 28 (2019/12/18)] includes one particularly interesting feature: Enhancement JDK-8234049 ["Implementation of Memory Access API (Incubator)"].
It's now over two years since the release of JDK 9, and with it, the switch to a time-based rather than feature-based release schedule. It seems incredible that it took very nearly eleven years to get from JDK 6 to JDK 9, yet in just over two years, we've gone from JDK 9 to JDK 13.
Each release under this new strategy provides a smaller set of features than we had in the old major release approach. What we're seeing, though, is the overall rate of change is faster than it's ever been, which is a significant advantage for keeping Java vibrant and attractive to developers.
Hi, Spring fans! What a week! I've just returned from Prague, the Czech Republic, where I was for the epic Geecon Prague 2019 event. (Thanks for voting my talk on Reactive Spring the #1 talk, Prague!). Now, I'm in Nantes, France, the DevFest Nantes show. I'd never been to Prague and I've never been to Nantes. So how's that for cool first-time appearances in one week?
Tonight, I fly to Paris, France, for customer meetings. Then, I fly on Thursday to St. Petersburg, Russia, for the Joker conference, where I'll be presenting on testing. I'll be co-presenting with Spring co-founder, my friend, and hero, the one, the only, the amazing and inimitable, a veritable font of kindness and wisdom, Juergen Hoeller! Then, on the 27th, I fly to Chicago. It's shaping up to be quite the week!
Today, we would like to introduce you to Trackman, the open-source, execute-commands-as-a-workflow tool. In this post, we take a closer look at what it is, why we need it, and how to best implement the tool. Let's get started.
You may also like: Most Useful Linux Command-Line Tricks
Trackman is a command-line tool and Go library that runs multiple commands in a workflow. It supports parallel steps, step dependencies, async steps, and success checkers.
I had the opportunity to meet with Georges Sabb, V.P. Software Development, Java Platform Group; Donald Smith, Sr. Director Product Management; Sharat Chander, Sr. Director Java Product Management and Developer Relations; Chad Arimura, V.P. Developer Relations, all with Oracle, and Aimee Lucido, Java Engineer, and author of Emmy in the Key of Code, following the announcement of the general availability of Java SE 13 (JDK 13) as part of the six-month feature release cadence.
After four-plus years of trying to get Oracle to provide insights for the Java Research Guides I've been conducting for DZone.com, I was pleased that they want to reengage with the developer community.
Following the recent announcement of the candidate JEP on sealed types (preview), Gavin Bierman's message "Draft JLS spec for sealed types" on the OpenJDK amber-spec-experts mailing list announces "a draft language spec for sealed types" and provides a link to that draft. That message also states: "This spec doesn't yet contain details on binary compatibility (Chapter 13) — to appear in the next draft."
You may also like: Candidate JEPs: Records and Sealed Types
In this post, I highlight some of the proposed changes to the Java Language Specification (JLS) for sealed types. It is important to keep in mind the tentativeness of these proposed changes: this is an of JLS changes for a feature associated with a JDK Enhancement Proposal (JEP).
Please go through the earlier article before reading this article. I will assume the strategy defined in first article is clear before reading ahead. This article will focus on multiple releases in parallel. A software team working on two or more releases at a time may refer to this strategy.
Let’s consider two releases starting in parallel from today.
The release of Scala 2.13 had been in the works for quite a long time, but it was finally released last month. With the release of this version, there are quite a few changes that Scala has brought for the users.
The intent of this post is to explain some of the features Scala has introduced/improved since its previous version.
In this article, we focus on new features that Scala 2.13 has in store for users and whether you should migrate to Scala 2.13. I'll try to summarize all related knowledge in this blog, including documentation and the release notes as well.
JDK 13 is currently in Rampdown Phase 1 (RDP 1), is scheduled to enter Rampdown Phase 2 (RDP 2) in a little over one week (on July 18, 2019), and is tentatively scheduled for General Availability on September 17, 2019. What this means, of course, is that it's time to start thinking about JDK 14! This post references and summarizes some of the online resources related to JDK 14 that are starting to appear.
The main OpenJDK JDK 14 page is the best place to start when wishing to see an overview of the release and its progress. Besides a reference to its associated specification (JSR 389: "Java SE 14 Platform"), the only other information available on this page as of this writing is a simple "Status" paragraph that references development repositories and the JDK Enhancement Proposal (JEP) process.
TechRepublic recently published an article about languages that developers love and those that they hate. This produced an interesting set of results since Java was the third most loved language as well as the second most hated. Clearly, Java, as a language, polarizes opinion. When I tweeted about this, I got one reply from Bjarne Stroustrup, the creator of C++:
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
I think he has a point.
Hi, Spring fans! Welcome to another installment of This Week in Spring! This week, I’m in... I’m home! Look at that! I’m home for the epic SpringOne Tour San Francisco event. I’m super excited to be here in this amazing weather with an amazing community. It’s been a busy week though! Last week, I returned from Spain for my kid’s graduation, and I am still so so proud. Tomorrow, I fly to Cork, Ireland, for the Cork JUG, and then, it’s off to London for a wedding. So, lots of travel, but a bit of a lighter load.
We’ve got a lot to cover, so let’s get to it!
This week, we hosted a webinar covering the most important features for developers from Java 12. The recording is now available for those of you who missed it or want to go back over some of the details. In the following video, you’ll find a list of the resources (links) from the video, and answers to the most relevant questions.
Deploying Spring Boot 2.x applications in WebLogic Versions 12.2.x is simpler than deploying those in WebLogic 12.1.x using Gradle build. I was struggling with the deployment of 2.x applications in 12.1.x version of WebLogic. There is no issue if you use Maven to build. But, using the Gradle build is complicated. But, finally, after some research got the solution and deployed successfully. Today, I will demonstrate how to deploy 2.x applications in 12.1.x version of WebLogic. Let's start. For my project, I'm using below tech stack:
a. Gradle 4.5+
b. Spring Boot 2.1.1.RELEASE
c. Java 8
d. WebLogic 12.1.3.1
e. javax.servlet 4.0.1 (Excliptly defining because of older WebLogic)