Posted by Adrian Mott on Tue, Jan 24, 2012 @ 06:50 AM
We've made some great progress on the HubSpot App Marketplace over the past few months, and think it's a fine time to hold our next HubSpot Hackathon. We're really excited about the possibilities and potential of creating apps on the HubSpot Platform and in the marketplace and are holding another Hackathon, coming up on Thursday 2/16 at 6pm at HubSpot Headquarters in Cambridge, MA, read more on the Eventbrite page here (please sign up!):
http://hackathon2.eventbrite.com/
We're also giving out some very special prizes as a part of this Hackathon, including the opportunity to have dinner with Dharmesh Shah, HubSpot CTO and prominent Angel Investor as well as Yoav Shapira, former VP of Engineering at HubSpot and now our VP of Platform Strategy. There's also the opportunity to come in to HubSpot and hack on your app for an afternoon with some awesome HubSpot developers and product folks. Check out the page linked to above to see how your app can qualify. This event will go late into the night as you might imagine, stay as late as you want of course, but we're also going to be letting any app that goes live within 24 hours of the event to qualify for the prizes.
Some of the new features we've implemented and are working on are OAuth support, ratings and reviews and new APIs like Prospects and Keywords. OAuth opens up the HubSpot app marketplace customer base to all HubSpot customers, giving your app great visiblity and potential user base. Of course, we're also working on billing through the HubSpot Marketplace, but that's not quite ready yet ;). You can read more about the HubSpot Platform and Marketplace on our new developers site here:
http://developers.hubspot.com/
We'll be proving food and drinks for the event, as well as some cool HubSpot shwag for apps that go live at the event. Come hang out with the best developers in Boston and hack apps with us. Hope to see you at the Hackathon!
Posted by Yoav Shapira on Fri, Jan 13, 2012 @ 08:43 AM
At HubSpot we use Graphite for most of our operational graphing needs, tracking such things as server uptime, response times, response codes (errors, etc.), cache layer capacity and hit rates, and more.
We also use Jenkins (formerly Hudson) for continuous integration, since we like to deploy very often. Jenkins, like all systems, can have capacity bottlenecks where there are no build executors available to run a build. This results in delays that frustrate developers and slow us down.
But how often does it happen? When should we add Jenkins nodes to our cluster?
One of our developers, Jeremy Katz, has recently written a script to track just this using the Jenkins API, and push the results to Graphite for easy viewing and analysis. He went a step further, open-sourcing his script under the Apache License.
Read more information, and enjoy the script, on Jeremy's blog.
Posted by Yoav Shapira on Mon, Jan 09, 2012 @ 04:17 PM
Earlier today, we open-sourced all of the social media & Twitter app data collected and curated by oneforty, the great local startup HubSpot acquired a few months ago. This means the data is fully available for the public to use and enjoy.
In addition to the data itself, there is technical documentation as to its format, tools to import it into other systems, and human-friendly instructions for working with this data in Microsoft Excel.
Get it on GitHub: https://github.com/HubSpot/oneforty-data (http://bit.ly/onefortydata)
Like most software companies these days, HubSpot relies on a variety of open-source tools, and we generally try to continue any patches or fixes back to the open-source projects we use. We also have a number of engineers working here who are committers or contributors to a variety of projects.
Today we took the next step, by open-sourcing the data itself, which was one of the main and most valuable oneforty artefacts. The data is licensed under the Creative Commons License, and you are free to use it in numerous ways. We just ask for a small attribution, please.
It looks like at least one company, SocDir (@socdir on Twitter), is planning to use this data in interesting ways.
If you are curious about Twitter applications, watch SocDir and/or have fun working with this data yourself. We're not sure yet how much time we'll spend maintaining it ourselves, but patches (GitHub pull requests) will likely be very welcome.
Posted by Yoav Shapira on Fri, Dec 09, 2011 @ 09:56 AM
I recently (as in yesterday) learned that HubSpot is mentioned and discussed in a new book by Phil Simon, "The Age of the Platform."
The book explains and elaborates on many of the principles we often cover here, on this blog, like how open platforms that enable 3rd parties to innovate offer far larger long-term beenfits to customers.
There are simply so many smart people out there in our flat world that if you're not enabling them to build stuff, you are missing out on huge potential wins. With standards for APIs, high-speed networks, and other technology infrastructure pieces becoming available to more of the world, the talent pool is bigger than it's ever been.
The book talks about how different companies, like Google, Apple, Twitter, and Facebook, take advantage of the above to improve their products, delight their customers, and grow their businesses.
It's a good read, recommended even without the HubSpot part, which is short.
By the way, as long as I'm issuing out recommendations, I also want to give a shout-out to Sam Ramji's excellent presentation on Slideshare: "Amundsen's Dogs, Information Halos, and APIs." Very worth clicking through, although it's a bit long.
Posted by Adrian Mott on Wed, Nov 30, 2011 @ 01:52 PM
We're excited to announce the release of a brand new APIs on the HubSpot Platform: Prospects API. This API joins the 5 marketing APIs that are already in the HubSpot ecosystem.
Prospects API enables developers to access HubSpot customer website traffic data and a variety of data associated with that traffic, including company information, number of visitors and page views, as well as geographic data including city, region, country and latitude and longitude data. All of this data is really useful, especially for integrations and external apps that want to take advantage of traffic data like this.
The new Prospects API also integrates with lead data, so as an API user, you can see if a particular company has actually had leads convert through HubSpot as well. Through the leads API, you can look up these folks by searching for the company they are from.
The API also has a search feature that will let you search for prospects by their geographic location (city, region, or country). As a bonus, there's also a typeahead feature that let's you only specify some of a company name in order to get back what you're looking for. Very useful for anyone trying to create and app that can search for prospects, map them, etc...
To see some sample output from the API, check out this URL:
https://hubapi.com/prospects/v1/timeline.json?hapikey=demo
Here's some sample output:
Posted by Jonathan Kim on Tue, Nov 22, 2011 @ 11:43 AM
This was first posted on my blog (jonathan-kim.com). You can check out the original post, if you're interested.
The other day, the project manager for my team (Brian McMullin) came to me with a simple request: he wanted to change the text of the call-to-action button in one of our daily emails. His research suggested that the people who were receiving that daily email were actually forwarding it on to other people in their organization, so Brian wanted to target them a bit better. But what if we could target them both a bit better?Well today, you can.
The code
I like it when people get straight to the point, so here's the code. If you want an explanation of how I got it and why it works, please continue reading :]
<p class="cta1">
This will only appear when reading an original version.
</p>
<p class="cta2" style="display: none">
This will only appear when reading a forwarded version.
</p>
<style type="text/css">
blockquote .cta1, .WordSection1 .cta1 {
display: none !important;
}
blockquote .cta2, .WordSection1 .cta2 {
display: inline-block !important;
}
</style>
My impromptu research
I noticed that many of the forwarded messages I received in the past displayed the original sender's message, but in a slightly different format, usually indented. With that in mind, I emailed the entire development team at HubSpot and asked everyone to forward the email back to me, along with the name of their email client. I even wrangled some sales people into doing it so I could get a good representation from people using Microsoft Outlook. It turns out that all email services take your original message and conveniently wrap it in a div (with a class) or a blockquote, meaning you can use that as a CSS selector. It's so stupidly simple.
Show me an example
Original version of the email: 
Forwarded version: 
How to use it
Stick that piece of code in the body of your email (putting it in the head section makes it more susceptible to being parsed out). Then apply the class "cta1" to the element you want to show in the original, and cta2 to the element you want to show in the forwarded version. Make sure to also add the CSS declaration "display:none" to the elements that have the cta2 class on them, so they're hidden by default. When your recipient is reading a forwarded version of the email, the code snippet will take effect by hiding the original and showing what was previously hidden.
Some caveats
Believe it or not, Gmail is doing ungodly things to make email design miserable. Campaign Monitor has a really awesome chart showing email compatibility across clients, and Gmail and Android are the worst, perhaps even worse than Blackberry. They don't support external css blocks, which makes this technique completely ineffective. What about just hiding the second call-to-action so it's not awkward?They've thought of that too. Gmail scrubs your email for anything, and I mean ANYTHING, that can hide an element on a page. Here's a short list of the hacks I've tried:
- CSS "display: none"
- CSS "visibility: hidden"
- CSS "text-indent: -9999px" or "text-indent: 9999px"
- CSS "margin-top: -9999px" or "margin-bottom: 9999px"
- CSS "position: absolute" + "top: -9999px"
- HTML5 "hidden" attribute
If you find a way to make it work in Gmail, please share. It's true that you can do stuff using server-side requests and header parsing to return different images. If you want to go that route, good luck :P
When to use (or not use) this technique
If your email list is mostly composedly of Gmail users, you probably shouldn't use this technique. You also probably shouldn't use it to spam people. At HubSpot, over 50% of our email recipients view these emails on some version of Outlook. About 20% view it on Apple Mail, and about 15% view it on an iPhone. Only 6% of our customers actually use Gmail to view our emails. Just the same, it's a good idea to make sure the email still looks natural with both call-to-actions displayed simultaneously.
Further reading
Hopefully this simple little technique sets your mind ablaze with other ideas to provide value with simple hacks. If you're interested in pushing the envelope in the email sector, the guys at Litmus are doing some pretty amazing stuff. Here's some discussion behind the secret sauce that puts them ahead of the pack in terms of email analytics:
They're my source for the email analytics used in this article. I highly recommend signing up with them and getting solid data on your email demographics and baseline click-through rates before attempting any of the above.
Posted by Adrian Mott on Fri, Nov 11, 2011 @ 09:35 AM
My first few months on the HubSpot development team has been an great experience, not only from a learning perspective, but also from seeing first hand and participating in the future of marketing. Even if you believe that traditional marketing still works and you or your company practice traditional marketing techniques, there's no denying the effectiveness of inbound marketing - and it's only going to get more popular and prevalent over time as the web and web apps continue to gain in popularity and business effectiveness.
Creating marketing web applications that let marketers more easily do inbound marketing is what we've aimed to do here at HubSpot, with pretty good success so far. Now, as we open up our doors and create an open platform on which to build apps, the future of marketing lays in the hands of you guys - the developers.
We're certainly going to be as accommodating as possible: the public HubSpot marketplace will be launched soon, soon to follow there will be billing incorporated into the marketplace, making it easier for people to make real money through marketing apps. We'll continue to release more APIs to supplement those that already exist, look for announcements around a Keywords API and Prospects API coming soon. We'll also be working hard to lower the barrier of entry to the HubSpot Platform for HubSpot customers by changing our authentication model over the coming months.
Going big is something that we like to talk about here at HubSpot, and part of that mantra is being as open and accommodating to developers outside of the company. We're believers in the bazaar mentality, especially as it has to do with platform ecosystem and development. Not only do we want the development community to help us change the face of marketing forever, we need it. Only together can we change an industry for the better moving forward and get out of the old marketing practices that we're now blocking out. A good analogy that I use is that inbound marketing is "opt-in", which enables a world of reliably and efficiently finding what you're looking for. Old marketing techniques are more like "opt-out" except the problem is that opting out usually doesn't work...
If you're reading this and I have you wanting to explore the platform and potential ideas for apps, head on over to our developer documentation, which also includes the App Marketplace docs that will give you the lowdown on creating a HubSpot app. If you're wondering about ideas for inbound marketing apps, check out some of the apps that exist already, then head over to our ideas site, where HubSpot users throw new app ideas the community's way all the time.
As usual, we want fedback on how we're doing so far. If you're and app developer and think we could improve on something, please DO NOT hesitate to let us know. We'll do our best to be totally transparent and work to improve things over time. If you have a suggestion, jead over to our Discussion Group and drop us a note.
Posted by Adrian Mott on Tue, Oct 25, 2011 @ 03:46 PM
It's pretty much common knowledge that a marketplace is a place where parties take part in the ancient ritual of exchanging goods or services. As part of this exchange, feedback has proven to be an intrinsical part of the exchange, letting providers learn from the use of their products and services so that they can improve over time. So as a natural progression of our Marketplace here at HubSpot, we're implementing ratings and reviews that will give users more interaction with the apps that they're using everyday.
As the HubSpot App Marketplace grows over time, it's important for us to provide HubSpot customers ad customers with the best overall experience within the product. Reviews and ratings help users understand what sort of experience they're in for should they decide to use an app.
To make it possible for users to imput these ratings and reviews, we're also giving each app it's own public page in the HubSpot Marketplace, accessible to anyone without having to be logged into HubSpot. App promotion is something that we care deeply about, and hope that these new public pages will help us and our development community promote their apps with greater success.
We're working really hard to improve the Marketplace, thus we'll be working to add some other features in the near future. If you are interested in writing an app for HubSpot, these links are a good place to start. Please let us know if you have any questions!
Posted by Dan Abdinoor on Fri, Oct 14, 2011 @ 09:00 AM
Each Ferrari is a work of art that you can drive. The engine and powertrain are derived from the latest F1 racing designs. The suspension geometry is optimized for the speed and conditions of a race track. The carbon-fiber bodywork is hand-laid in molds designed to aerodynamic perfection. The components are assembled by a small workforce of craftspeople. Photographs are taken throughout the process and provided to the future owner in what is called “The Baby Book.” The end result is a finely-tuned, yet capricious, machine.
Each Toyota is an example of modern manufacturing techniques and efficiencies of scale. The engine is the tenth refinement of a ten-year old design. The suspension is designed for rutted asphalt and concrete highway sections. The interior is a lesson in compromise: How to perform necessary functions while remaining unobtrusive. The components are assembled by a fleet of robots and humans on a perfectly-timed assembly line. The end result is a dependable and predictable machine.
If you are fortunate enough to own a Ferrari, you quickly learn to live with the maintenance of such a machine. An oil change with six quarts of full synthetic runs $300; expect to buy a new set of tires each year for $4,000; suspension components are replaced every few years for $25,000. The price for driving a work of art is high and the average usage for an Italian exotic is just 3,000 miles a year.
If you own a Toyota, you get a predictable maintenance schedule. There are $30 oil changes and $500 service intervals. Plenty of spare parts are available direct from Toyota or the network of other compatible suppliers. You can get your Toyota serviced just about anywhere. You can push your Toyota to 100,000 miles and beyond.
Software and cars are similar beasts. Both are usually considered as objects, whole entities, rather than by the composition of their sub-systems. Cars and software also share similar development tracks: usually there is a sexy prototype to show and then layers of safety checks and compliance tests get added on. Both have to be maintained and repaired, whether on a schedule or because of emergencies.
You are probably starting to see my point now. When you build software and systems, you want to build a Toyota, not a Ferrari. The Ferrari of software would leave you troubleshooting complex algorithms, or looking for drivers for an experimental key-value store. Aim for reliability through iteration and refinement. One novel idea at a time is sufficient. Think about how and where failures will occur and plan for them. Identify the parts of your system that might not scale, or might not fit every use-case, and make them easy to replace.
Your software should be something you can “drive” every day without a lot of headaches. Building a Toyota is every bit as challenging as building a Ferrari -- the tradeoffs may not seem sexy, but they are worth it. Good software will be just like a Toyota: dependable, efficient, predictable, and in most cases affordable, too.
Have you built your software as a Toyota or a Ferrari?
Posted by Dan Abdinoor on Fri, Oct 07, 2011 @ 09:00 AM
October marks the 40th month that we have been practicing Scrum at HubSpot. Obviously we have learned a lot of lessons over that time. But one of the best things we have learned is how to do the basic things right. One example is the sprint retrospective meeting which at first was an awkward, confrontational, waste of time.
Here is the definition of the retrospective from Scrum Alliance:
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.
The sprint retrospective should be time-boxed to three hours.
That description is nearly useless. And a time-box of three hours? Who has three hours for these meetings?
But sure enough, sprint after sprint, we found ourselves in a room asking everyone to reflect on the past sprint. It was an awkward meeting filled with questions like "How did you feel about the stories?" and "Why were your tasks not estimated accurately?" One team at HubSpot started to call this meeting the "Burrito of Tears" because it was not fun, and because they held it during lunch at the nearby Boca Grande.
Eventually the purpose of this meeting became clear: to shine some sunlight on the past sprint. We needed to get together and be totally open and honest. So we started to discuss why some things did not meet our expecations. Did we get slammed by bugs? Did we screw up in our initial tasking and miss an important part of the solution? What could we change so that we do not have this problem again?
The sprint retrospective can feel like a 5 Whys. When we identify something that is not perfect we dig down until we find a systematic issue. Usually it is something in the way that we practice Scrum, and we change it. Over time we got our practice finely tuned. There are still surprises but we learn from them.
The retrospective also helps us to identify the things that went well so we can try to repeat them in future sprints. Some positive things we have discovered:
- We were able to get more done by dividing into teams building/consuming an API.
- We had better testing by identifying the use cases upfront.
- We like having our standup right before lunchtime so we do not have to break our concentration twice.
Finding the things that went well is just as important to having succesful future sprints as preventing the things that did not go well. Not to mention, morale gets a nice boost when you end the retrospective discussing what went well for the team.
The retrospective is about the process more than the people. It does not have to be a confrontational blame-throwing meeting. It can be both enlightening and productive. And it does not take anywhere near three hours!
Have you found helpful ways to make Scrum work better for your team?