Portland Docker Meetup & Olympia Stuff That Isn’t RDBMS

The next Portland Docker Meetup is going to be at New Relic offices in big pink. It looks to be a solid line up of topics, which I’ll be kicking off with a Docker intro. There will also be a Q & A session, lightning talks and some topic coverage of drone.io (I’m definitely looking forward to hearing about this topic).

Database Stuff that aint RDBMS in Olympia

Fast forward to April 10th and I’ll be boarding the flanged wheels to come and visit Olympia, Washington to speak at the Olympia South Sound Developers User Group. The topic will be on “Database Stuff that aint RDBMS“! I’ll have more on that presentation, the deck and any other things that come up related to this. I *might* even have a video of the presentation afterwards.

WebStorm JavaScripting & Noding Workflow Webinar Recording

Today the JetBrains team wrapping up final processing for my webinar from last week. You can check out the webinar via their JetBrains Youtube Channel:

JavaScriptFor even more information be sure to check out the questions and answers on the JetBrain WebStorm IDE blog entry. Some of the questions include:

  • Q: How to enable Node.js support in PhpStorm (PyCharm, IntelliJ IDEA, RubyMine)?
  • Q:How to enable autocompletion for Express, Mocha and other libraries?
  • Q: Is it possible to debug a Node.js application that runs remotely? Is it possible to debug when your node and the rest of the dependencies (database, etc.) are running in a VM environment like Vagrant?
  • Q: Does the debugger support cluster mode?

…and others all here.

I’ve Got a JavaScript & Node.js Webinar, Webstorm Tutorial Videos, Work & Flow With JavaScript Development and More…

Webinar: Node.js Development Workflow in WebStorm

This coming week I’m doing an intro to work and flow with Node.js JavaScript Programming that I’m working with JetBrains on. In the webinar I’ll be covering the following key topics in the webinar:

  • Open an existing project & getting WebStorm configured for running, testing and related working tasks.
  • A quick tour of other IDE features that help with daily work. Some in pretty huge ways.
  • Running WebStorm & debugging Node.js JavaScript applications.
  • Checking out Mocha, how it works and what it gives WebStorm the power to do. Then we’ll write a few tests & implement that code too.

All this will include Q & A throughout and at the end of the webinar. Be sure to register soon!

WebStorm Tutorials: Learning Shortcuts, Customizing Layout and Others

These WebStorm Tutorials have been put together by John Lindquist @johnlindquist for JetBrains. There solid, quick snippets of useful WebStorm usage. Two that I’ve found really useful I’ve included here:

John also has a lot of other great totally kick ass material out there. So check out his blog @ http://johnlindquist.com/ and follow his youtube channel too.

Coming Up in the Near Future, The Work & Flow of JavaScript Development

I have a new course I’m working on right now for Pluralsight, that will take these basic precepts and dive even deeper into the daily workflow of the JavaScript Developer. Whether it’s client side hacking or server side coding, I’ll be diving into a whole lot of JavaScript goodness. If you’d like me to ping you when the course is done, hit me up on Twitter @adron and just let me know. In the meantime get a Pluralsight subscription (free to sign up and at least give it a try) and check out these courses by myself and others.

Going Live, Data & Pricing @ Orchestrate

Over the last few months while working on the prototype around Deconstructed I’ve been using the Orchestrate service offering exclusively. With their service around key value and graph store easily accessible via API it was a no brainer to get started building ASAP. Today, that service goes full beta! You can get the full lowdown at the Orchestrate site.

You might recall that I mentioned Orchestrate a while back when they lept into the PIE Class a few months ago. So here’s a few quick thoughts on the release and what Orchestrate is.

The basic premise is Orchestrate provides full-text search, time ordered events, graph, key value storage and a lot more. All of these capabilities are offered via an API that create a product that’s extremely easy to get started. Think about what you’d need to do to get full-text search against a key value setup. Really think about it. Yeah? That’s a lot of steps. With Orchestrate you just sign up and start using it. Think about setting up a graph store and managing it on production systems. Yeah? Lot’s of work once it gets used. Again, just sign up, it’s all there, the graph to the key value to the event series and more. All the NoSQL juice you need located in a single service so you’re not fighting and maintaining multiple databases, nodes or whatever you’re working with.

Sing up. Use.

I will copy one thing from the press release….

  • Ad hoc search queries with Lucene
  • Event and time-ordered storage for activity feeds, sensor data
  • Create and query graph relationships
  • Easy to understand pricing
  • Data export at will – no lock-in
  • Standards compliant data security protocols
  • Daily data backups
  • Bulk data loading
  • Daily and hourly usage monitoring
  • A single, simple interface – JSON data in/out
  • Designed to complement existing databases and MBaaS services
  • Client libraries for Java, Node.js, and Go. More on the way!

Using Orchestrate

There are quotes in the press release, but I’ve got a few myself. I’m working to build out a prototype service that I and Aaron Gray will be releasing soon. Our startup is called Deconstructed, but more on that later. Without Orchestrate my dev cycle would be longer each day, as I battle with maintaining the data sources that I need. Without it I would have spent another 2-3 weeks setting up and staging nosql database technology. All things I didn’t really need to do. I needed to focus on the service, the value that we’ll soon bring to our customers.

It really boils down to this, and don’t get me wrong, I’m a total data nerd. But when it comes to building a product or service, the last thing I want to do is fight with managing the data anymore than I have to. That notion inspired me to write “Sorry Database Nerds, Nobody Actually Gives a Shit” which still holds true. I can’t think of a single business that wants to sit around and grok how an index works in a key value or what the spline of text-search queries is going to be.

Pricing

Pricing is sweet, for many that want to try it out things are free. Prices go up a bit more from there, but if you fall into the pricing you’re doing some business and ought to be rolling in a few bucks eh!

The interesting thing to me about pricing is that they’ve structured it around MOp, which stands for MegaOps. More specifically that’s one million API calls or one million operations.

Summary

If you write code, even a little or if you manage data you should do yourself the service and check out what Orchestrate has built. It’s a solid investment of time. I’ll have a lot more on Orchestrate and how we’re using the service for Deconstructed and more on using the service with JavaScript in the coming months. Keep your eyes peeled and I might even have some Dart and C# magic thrown in there to boot! Check em’ out, until later, happy hacking.

Recruiters -> Software Developer Referrals, I Know Em’, Here’s How You Know Them

This is a public letter to all recruiters, human resources or other professionals that are in a *hiring department* that would like to garner referrals from me. I like to categorize my referrals into junior and senior software developers. This is not my interaction process with startups & early round companies, I know you and you know me, things work differently, so if you’re in a startup and looking for people this doesn’t apply to you. This is a letter to help guide how I can help all parties involved in the best way possible.

NOTE: I’m not a recruiter, not intending to be, nor do I work for any recruitment agencies or groups. This is something I do because I enjoy being involved with the tech scene of Portland and have great sympathy for people looking to join good teams. I fought years to find good teams and have enjoyed working with these teams. Matter of fact, I’d say a good team is orders of magnitude more enjoyable to work with than the not good teams. In other words, I try to make things not suck for everybody involved!  😉

For junior developer referrals, I have a few basic requirements and information that I’d like to know if there is a specific job in mind. If you’d just like to talk, I’ll also put you in touch with a junior developer based on this criteria.

  1. For the junior developer the positions should be of reasonable commutes, especially in the current software development market. This means that the commute, one way, should not be anymore than 10-15 minutes either by biking, walking or taking transit. If they want to drive, that’s their concern, but I don’t want to condemn anyone to ever being stuck with a forced auto-dependent commute.
  2. Is there opportunity that the junior dev will be working with other senior developers who will pair code, do code review and otherwise support the individual in a positive and enthusiastic way?
  3. Is the company active in the local community and supportive of new employees and existing employees being involved? Will the encourage and allow the junior developer to get involved and possibly attend workshops, courses, meetups and even conferences that may be during business hours (but likely most are not)?

For senior software developers this gets to be even more particular, especially in Seattle, Portland, San Francisco, New York or Vancouver BC. If I’m going to refer anybody the following items are a baseline.

  1. Does the job offer remote work or some remote work days? How does the team currently communicate with remote employees and what is the split of remote employees vs. in office employees?
  2. Not just is there opportunity to, but is there active pairing, continuous integration or delivery setup and being used?
  3. What is the current management paradigm around architecture decisions, user experience (UX) and other items that are often peripheral to the software development that occurs?

If these questions can be answered in the affirmative then I have some referrals for you. Even if they aren’t, these questions and this information should become standard on any job description, in MANY ways more so than the technology list of skills that are all to common. This last part is something to note for people hiring, not just recruiters.

I’ve also talked more about this far in the past (in tech years). I’ve spent many solid years hiring, firing and generally building teams of people. The following has inadvertently become kind of a series about suggestions to fix the job posts, and where and what the baseline is for building a A-game Team. Much of these suggestions hold true still today.