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.
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.
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.
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.
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?
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.
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?
Not just is there opportunity to, but is there active pairing, continuous integration or delivery setup and being used?
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.
NOTE: If you just want to check out the code bits, scroll down to the sub-title #symphonize #hacking. Also important to note I’m putting the library through a fairly big refactor at the moment so that everything aligns with the documentation that I’ve recently created. So many things may not be implemented, but we’re moving toward v0.1.0, which will be a functional implementation of the library available via npm based entirely on the documentation and specs that I outline after the history.
There are two main reasons why I chose Orchestrate.io and a data generation library as the two things I wanted to combine. The first, is I knew the orchestrate.io team and really dug what they were building. I wanted to work with it and check out how well it would work for my use cases in the future. The ability to go sit down, discuss with them what they were building was great (which I interviewed Matt Heitzenroder @roder that you can watch Orchestrate.io, Stop Dealing With the Database Infrastructure!) The second reason is that my own startup that I’m co-founding with Aaron Gray (@agray) needed to use key value and graph data storage of some type, somewhere. Orchestrate.io looked like a perfect fit. After some research, giving it a go, it fit very well into what we are building.
December then rolled into the standard holiday doldrums and slowdowns. So fast forward to January post a few rounds of beer and good tidings and I got the 3rd in the series published titled Getting Serious With Symphony.js – JavaScript TDD/BDD Coding Practices (3/3). The post doesn’t speak too much to symphony.js usage but instead my efforts to use TDD or BDD practices in trying to write the library.
Slowly I made progress in building the library and finally it’s in a mostly releasable state now. I use this library daily in working with the code base for Deconstructed and imagine I’ll use it ongoing for many other projects. I hope others might be able to find uses for it too and maybe even add capabilities or ideas. Just ping me via Twitter @adron or Github @adron, add an issue on Github and I’ll be happy to accept pull requests for new features, code refactoring, add you to the project or whatever else you’re interested in.
#symphonize #hacking
Now for the nitty gritty. If you’re up for using or contributing to the project check out the symphonize.js github pages site first. It’s got all the information to help get you kick started. However, you can keep reading as I’ve included much of the information there along with the examples from the README.md below.
NOTE: As I mentioned at the top of this blog entry, the funcitonal implementation of code isn’t available via npm just yet, myself and some others are ripping through a good refactor to align the implementation fo the library with the rewritten and newly available documentation – included blow and at the github pages.
[sourcecode language=”javascript”]
git clone git@github.com:YourUserName/symphonize.git
cd symphonize
npm install
[/sourcecode]
Using The Library
The intended usage is to invocate the JavaScript object and then call generate. That’s it, a super simple process. The code would look like this:
[sourcecode language=”javascript”]var Symphonize = require(‘../bin/symphonize’);
var symphonize = new Symphonize();
[/sourcecode]
The basic constructor invocation like this utilizes the generate.json file to generate data from. To inject the json configuration programmatically just inject the json configuration information via the constructor.
[sourcecode language=”javascript”]
var configJson = {"schema":"keyvalue"};
var Symphonize = require(‘../bin/symphonize’);
var symphonize = new Symphonize();
[/sourcecode]
Once the Symphonize data generator has been created call the generate() method as shown.
That’s basically it. But you say, it’s supposed to do X, Y or Z. Well that’s where the json configuration data comes into play. In the configuration data you can set the data fields and what they’ll generate, what type of data will be generated, the specific schema, how many records to create and more.
generate.json
The library comes with the generate.json file already setup with a working example. Currently the generation file looks like this:
[sourcecode language=”javascript”]
{
"schema": "keyvalue", /* keyvalue, graph, event, geo */
"count": 20, /* X values to generate. */
"write_source": "console", /* console, orchestrateio and whatever other data sources that might come up. */
"fields": {
/* generates a random name. */
"fieldName": "name",
/* generates a random dice roll of a d20. */
"fieldTwo": "d20",
/* A single lorum ipsum random statement is genereated. */
"fieldSentence": "sentence",
/* A random guid is generated. */
"fieldGuid": "guid" }
}
[/sourcecode]
Configuration File Definitions
Each of the configuration options that are available have a default in the configuration file. The default is listed in italics with each definition of the configuration option listed below.
“schema” : This is used to select what type of data structure type is going to be generated. The default iskeyvalue for this option.
“count” : This provides the total records that are to be generated by the library. The default is 1 for this option.
“write_source” : This provides the location to output the generated data to. The default is console for this option.
“fields” : This is a JSON field within the JSON configuration file that provides configuration options around the fields, number of fields and their respective data to generate. The default is one field, with a default data type of guid. Each of the respective entries in this JSON option is a self contained JSON name and value pair. This then looks simply like this (which is also shown above in part):[sourcecode language=”javascript”]{
"someBoolean": "boolean",
"someChar": "character",
"aFloat": "float",
"GetAnInt": "integer",
"fieldTwo": "d20",
"diceRollD10": "d10",
"_string": {
"fieldName": "NameOfFieldForString",
"length": 5,
"pool": "abcdefgh"
},
"_sentence": {
"fieldName": "NameOfFiledOfSentences",
"sentence": "5"
},
"fieldGuid": "guid"
}
[/sourcecode]
Fields Configuration: For each of the fields you can either set the field to a particular data type or leave it empty. If the field name and value pair is left empty then the field defaults to guid. The types of data to generate for fields are listed below. These listed are all simple field and data generation types. More complex nested generation types are listed below under Complex Field Configuration below the simple section.
“boolean“: This generates a boolean value of true or false.
“character“: This generates a single character, such as ‘1’, ‘g’ or ‘N’.
“float“: This generates a float value, similar to something like -211920142886.5024.
“integer“: This generates an integer value, similar to something like 1, 14 or 24032.
“d4“: This generates a random integer value based on a dice roll of one four sided dice. The integer range being 1-10.
“d6“: This generates a random integer value based on a dice roll of one six sided dice. The integer range being 1-10.
“d8“: This generates a random integer value based on a dice roll of one eight sided dice. The integer range being 1-10.
“d10“: This generates a random integer value based on a dice roll of one ten sided dice. The integer range being 1-10.
“d12“: This generates a random integer value based on a dice roll of one twelve sided dice. The integer range being 1-10.
“d20“: This generates a random integer value based on a dice roll of one twenty sided dice. The integer range being 1-20.
“d30“: This generates a random integer value based on a dice roll of one thirty sided dice. The integer range being 1-10.
“d100“: This generates a random integer value based on a dice roll of one hundred sided dice. The integer range being 1-10.
“guid“: This generates a random globally unique identifier. This value would be similar to ‘F0D8368D-85E2-54FB-73C4-2D60374295E3’, ‘e0aa6c0d-0af3-485d-b31a-21db00922517’ or ‘1627f683-efeb-4db8-8174-a5f2e3378c87’.
Complex Field Configuration: Some fields require more complex configuration for data generation, simply because the data needs some baseline of what the range or length of the values need to be. The following list details each of these. It is also important to note that these complex field configurations do not have defaults, each value must be set in the JSON configuration or an error will be thrown detailing that a complex field type wasn’t designated. Each of these complex field types is a JSON name and value parameter. The name is the passed in data type with a preceding underscore ‘_’ to generate with the value having the configuration parameters for that particular data type.
“_string“: This generates string data based on a length and pool parameters. Required fields for this include fieldName, length and pool. The JSON would look like this:[sourcecode language=”javascript”]"_string": {
"fieldName": "NameOfFieldForString",
"length": 5,
"pool": "abcdefgh"
}
[/sourcecode]
Samples of the result would look like this for the field; ‘abdef’, ‘hgcde’ or ‘ahdfg’.
“_hash“: This generates a hash based on the length and upper parameters. Required fields for this included fieldName, length and upper. The JSON would look like this:[sourcecode language=”javascript”]"_hash": {
"fieldName": "HashFieldName",
"length": 25,
"casing": ‘upper’
}
[/sourcecode]
Samples of the result would look like this for the field: ‘e5162f27da96ed8e1ae51def1ba643b91d2581d8’ or ‘3F2EB3FB85D88984C1EC4F46A3DBE740B5E0E56E’.
“_name”: This generates a name based on the middle, *middleinitial* and prefix parameters. Required fields for this included fieldName, middle, middle_initial and prefix. The JSON would look like this:[sourcecode language=”javascript”]"_name": {
"fieldName": "nameFieldName",
"middle": true,
"middle_initial": true,
"prefix": true
}
[/sourcecode]
Samples of the result would look like this for the field: ‘Dafi Vatemi’, ‘Nelgatwu Powuku Heup’, ‘Ezme I Iza’, ‘Doctor Suosat Am’, ‘Mrs. Suosat Am’ or ‘Mr. Suosat Am’.
So that covers the kick start of how eventually you’ll be able to setup, use and generate data. Until then, jump into the project and give us a hand.
I finally wrapped up my name server and DNS mapping needs with Name.com, Route 53 and Elastic Beanstalk. Since this was a little confusing I thought a short write up was in order. Thanks to Evan @evandbrown for helping out!
The first thing needed is a delegation set of name servers for your DNS and name server provider. These can be found by creating a hosted zone. The way to do this is open up the AWS Management Console and navigate into the Route 53 management area. The Route 53 icon is under the Compute & Networking section on the management console.
Beanstalk, Route 53 – Click for full size image
Upon navigating to the Route 53 console area click on the Create Hosted Zones button.
Create Hosted Zone – Click for full size image
When the zone is created then the delegation set can be found under the Hosted Zone Details. This delegation set now needs setup as the name servers for whoever, in this case name.com, is the domain provider.
Delegation Set – Click for full size image.
Open up the management console for the name server administration.
…
Upon adding them the list should look something like this.
Name servers list built from the delegation set of the hosted zone. Click for full size image.
Once the name servers are setup, those will need time to propagate. Likely this could take a good solid chunk of time, somewhere in the hours range likely, and don’t be surprised if it takes a little bit more than a day.
While the propagation starts navigate back to the AWS Management Console and open up the EC2 section of the console. On the right hand side of the Resources list there is a Load Balancers section. Click it.
Load Balancers – Click for full size image.
In this section there is a listing of all load balancers that have been created manually or by Elastic Beanstalk.
Load Balancers – Click for full size image.
Make note of the Load Balancer Name for selection in Route 53. This is what Route 53 needs in order to point an alias at for incoming traffic to that particular Elastic Beanstalk application. In this particular image above there are 4 load balancers listed, the easiest way to prevent confusion is to take note of the load balancer name at the time of creation, but this is the easiest way to find them otherwise.
Record Set – Click for full size image
Now when going back to the hosted zone to set it up with the appropriate information, create a new record with the appropriate name, in this case I was setting up the admin.deconstructed.io (no it isn’t live yet, I just set it up to test it out) to point to an alias target. Just leave the Type set to A – IPv4 address and click the radio control so that Alias is set to Yes. In the alias target select the appropriate load balancer for the Elastic Beanstalk (or whatever it points to) application.
That’s it, give it a few hours (or a day) and eventually the domain or subdomain will be pointed appropriately at the Elastic Beanstalk load balanced application.
I started to write a blog entry a few months ago about my time doing developer evangelism. First in practice, along with product management and team leadership and then as a full time developer evangelist with Basho. Then I felt many different things, nothing which translated into a very useful blog entry. Well past any motivation to write up where and what I was doing at the time and why I decided it wasn’t something I wanted to keep pursuing, I ran into this blog entry titled “Developer Evangelism The Whole Story“. At that point I thought, “alright, I’m going to add my two cents after all”.
For one of the same reasons Keith Casey wrote his entry. People have asked me numerous times about becoming an evangelist or advocate. Be sure to read Casey’s write up, and here’s mine to throw more into that fire.
Positives:
You’ll be able to go to all sorts of cities and meet a whole bunch of different people.
You’ll be on display and actually able to do something to improve the industry. Not just technologically but to help resolve sexism, discrimination and other issues and treat people well.
Do right by people as an evangelist and you’re set for a plethora of possibilities when you finally get burned out.
You get to play with all sorts of tech.
You get to travel a lot, which makes you really start to respect your home base, wherever that may be.
Negatives:
You’re barely ever home, usually you’re on the road with familiarity often becoming the stink of a plane or the confused expression as the TSA security circus actually recognizes you and just starts ignoring you.
Even though you can help improve the industry, you’re ability to make a home, make a difference where you live is dramatically reduced to basically nothing. For most people, considering civic involvement in the United States, this probably doesn’t even matter. For some, it’s destructively depressing.
If you get mis-portrayed, say something dumb out of jest, or the media mis-quotes you it can be anywhere from annoying to career limiting or ending. If you make the mistake of pissing of someone that has a lot of pull then it could also be super destructive – even if that person is a total jack ass and everyone routinely knows it and admits to it.
You get to play with all sorts of tech, but you lose a lot of credibility because you don’t actually build anything real anymore. This is a huge problem, and I’d even suggest most evangelists go work on an actual dev team every other year or so. It doesn’t matter who you are, you will start to be perceived as a shill of some sort by a reasonable amount of people, even though they could be extremely wrong in that perception.
Your home base, you often don’t get to have a real home base. You are a vagabond. For a musical definition, listen to Metallica’s “Wherever I May Roam”.
Now if you still think this is a great gig for you. Thicken up that skin, get some callouses and get ready for a bad ass trip that’ll teach you about all sorts of human interactions and more. But be prepared and keep a solid look out for burn out and the degradation of any of the situations mentioned above. If you do you’ll likely do well. If you’re still interested, here’s a few things to get your kick start in developer evangelism:
Get a social media presence, get it fast, and get a nick that you can use in almost all contexts. Don’t even pretend you can skip this step. The most successful evangelists have a huge social media presence and manage it. They manage it hard core, work it into a system, and learn efficient and positive ways to interact with that social media presence. Shut up, don’t even try to skip it, just go out there and manage it.
Make sure to spend at least an hour a day doing something technical. Hacking on Docker, writing some scripts or heaven forbid writing some actual code. This is massively important because you’ll find yourself losing direction all the time from the task switching and not getting to do these little technical things that will help you keep your edge.
Learn to speak. I don’t mean read a little book and think you know how to speak in front of a crowd. Likely, you really suck at it. I’m talking about practicing in the mirror, talk to yourself, record yourself and watch it and do all of these things without becoming nihilistic or pompous. Most of us tech speakers are so bad we’re lucky that the people in the industry are actually focused on the tech and not our stuttering horror of speaking abilities.
Drop all fear to speak with people in positions of power. Remember, everybody is human, don’t get intimidated and don’t intimidate.
Not that anybody in the software industry or tech industry or any industry needs told this but I’ll say it. Don’t overdo the drink. We’re all dangerously close all the time to being worthless drunkards. Some of us stay pretty functional on a drink or two, but that only lasts for a short time before you do indeed go downhill. Don’t deny yourself, you are NOT part of the one percent that can stay sharp and rot your brain. So keep the drink in check.
Find a way, anyway, to stay physically healthy. If you don’t the travel can very likely kill you. I don’t mean like “I’m tired and want to go to bed” killed but more like “hmmm, Tory Joe McQuerty here sure did see like they were fine, too bad we’re putting them six feet under” killed. Oh, the “I’m tired and want to go to bed” will happen all the time too, just make sure you keep that as the only killed you get.
Attain a huge amount of apathy for the extra overdose of everyone’s opinions about how everything sucks in the world. Many programmers are notoriously negative, especially if they work in the enterprise. It’s part of the daily war story if you get sucked in. Remember to stay focused on what’s important, your health and your loved ones, the job comes second. Anybody that tells you different, put them in that apathy category.
Never feel like you have to explain yourself when you need to take some family time or personal time. Just say you need to and do it. Even if you’re pretty close to people on your team, they need to respect that and let you get some time in. This is extremely important.
Don’t give to many fucks. Learn that at some point you gotta call it a day and turn in. Just drop it all and get a good night of sleep.
Summary: Think really hard about what you want when signing up for a dev evangelist or advocacy gig. It will wreck hell on your life, but it could be immensely rewarding too. But please, if you go into evangelism, practice at it and be prepared. I hate the idea of seeing more people burn themselves right out of the industry.
If you have anymore survival suggestions, please do comment!
You must be logged in to post a comment.