In 2017 I attended the DevNexus conference in Atlanta and wrote my thoughts of it at the time.  I was mildly critical of some of the content at the time and as I look back on that review I realize that some of my complaints may have been more due to my own shortcomings at the time rather than the fault of the presenters or organizers.  Whether I liked to admit it or not, I’d fallen out of touch with our industry.  I didn’t know what Docker was.  I hadn’t ever heard of Kubernetes and didn’t know a thing about “serverless”.  I wasn’t using Typescript, Angular, NodeJS - I didn’t even have Node installed on my laptop!  In the months that followed I decided it was time to refocus my dedication to improving my skill set as a developer and at least learn about many of the latest languages, frameworks and trends.  Rather than criticize the conference for not providing content that was suited for me, I realized that I needed to be in a place where the content **did **matter to me as a developer.  After all, conference content is nothing if not directly reflective of current and future industry trends.

The last few days I’ve been going through the Vue.js documentation to learn a little more about the framework.  I’m impressed in its simplistic, concise approach to front-end dev and even more impressed with their obvious attention to performance with the framework.  However, one item jumped out at me when going through the documentation that reminded me of another article that I’d read recently so I thought I’d share a simple refactor to one of their examples that could make a world of difference in the performance of larger Single Page Applications.

I recently had the opportunity to attend Connect.Tech 2017 and wanted to write up a quick review of the event.  I’ll start off by saying this won’t be your typical conference review as I was privileged to attend in a much different capacity than I normally do:

That’s right, I volunteered, and it was an amazing experience that I highly recommend.  In my past (ColdFusion) days I had seen a little bit of the dirty underbelly of the beast that is running a conference, but this experience pulled the curtain back just a bit more and let me gain a new respect for what people like Pratik and Vincent go through to put on events that so many of us take for granted in the tech world.  Running a conference is a labor of love.  There’s always a fire to put out or issue to address.  Audio issues, timing, setup, teardown...wait, what’s that...a speaker couldn’t make it?  Cost is another factor.  Conferences are **not **cheap.  One sponsor shared with me that they asked the facility for an extra power strip for their booth.  The technician asked them who they should charge the $101 dollar rental fee for the power strip.  **One hundred and one dollars.  *For a power strip!!  ***

I use the Database view/plugin in InelliJ IDEA quite often.  It’s actually become my “go to” editor for SQL scripts because of it’s responsiveness, the fact that it’s right there inside my IDE and the code completion and join hints are often times better than the DBMS vendor’s offering.  It’s pretty easy to open a new console to start writing queries once you’ve set up a datasource.  You can click the ‘SQL Console’ icon in the toolbar, or right click on the datasource and choose ‘Console’:\

One of the handiest features of Grails is the “flash” scope.  The flash scope is “A temporary storage map that stores objects within the session for the next request and the next request only, automatically clearing out the objects held there after the next request completes.”  It’s a handy way to send messages and errors around when dealing with form posts and redirects.  Since I’ve been working with Spark Java I’ve found myself missing this little feature so I decided to throw together my own implementation.  I’ve added the following closure inside of my main() method in my Bootstrap class:

The latest journey in my quest to see just how many new technologies and frameworks I can learn in one week involves Morphia.  Morphia is a “Java Object Document Mapper for MongoDB”.  In other words, it let’s us map our POJOs and POGOs to MongoDB Documents and persist them in MongoDB.  \

Right, so, on to the codes.  To get started with Morphia declare a dependency as such:

compile group: 'org.mongodb.morphia', name: 'morphia', version: '1.3.1'

Obviously you’ll need to make sure you’ve got access to a running instance of MongoDB before you try to connect/persist to it.  Next, create a domain class - we’ll call this one Person: