tag:blog.nahurst.com,2013:/posts Nathan Hurst's Blog 2017-01-18T18:17:31Z Nathan Hurst tag:blog.nahurst.com,2013:Post/843283 2015-04-20T18:55:20Z 2015-04-23T17:05:48Z I'm joining Teachers Pay Teachers

I’ve been programming for mobile for 15 years. “What?! Mobile wasn’t around in 2000,” you say? Well, you’re forgetting about the original mobile, the TI-83 graphing calculator.

BASIC on the TI-83 was my first experience with programming, and it all started because a teacher told me I could use calculator apps on tests if I made them myself. I’ve been programming ever since, and it has shaped who I am as a person. This is just one example of the profound effect teachers can have.

Today, I’m proud to announce I’m joining a company that helps teachers share these transformational experiences: Teachers Pay Teachers. Teachers Pay Teachers is the world’s first and largest open marketplace for educators to buy, sell, and share their original resources. It’s growing like crazy and has already paid out over $100M to teachers.

I’m excited to join a great team including:

  • Sha-Mayn Teh (previously an engineering manager at Google)
  • Adam Freed (previously COO at Etsy)
  • Jared Cohen (previously COO at Kickstarter)
  • Kirsten Nevill-Manning (previously director of FB recruiting)
  • Scott Carleton and Alexis Tryon (from Artsicle who I met during the good ol’ days at Dogpatch Labs)

If you’re interested in hearing more, ping me at nhurst@teacherspayteachers.com - I’d love to grab coffee, hear what you’ve been doing, and tell you what we’re up to!




]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/598916 2013-09-03T19:01:32Z 2014-06-01T01:08:39Z Understand the differences between iOS and Android
My name is Nathan, and I'm an Android fanboy. I've been investigating the differences between Android and iOS user experiences recently, and wanted to summarize my findings for you:

That's right: one of these things is not like the others. This is how it feels to use your iOS app that you directly cloned for Android.

Don't port your interface from iOS to Android directly. There's a minimal level of work you have to do to take your app from bleach to milk. Just take a look at these resources.

Pure Android will give you 80% of what you need to know in five minutes.
iOS 7, iOS6, and Android UI Element Equivalents will take you up to 90% in another five minutes.
Android Design Guide will take you up to 95% in a few hours.

To get the rest of the way, I'd suggest using Android device as your primary mobile device for a week at least.

If these types of user experience challenges interest you, we're hiring mobile engineers at Amplify. Feel free to contact me directly at nhurst@amplify.com if you're interested.
]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333133 2012-11-19T17:17:00Z 2014-06-01T00:51:17Z Discover unique gift ideas with GiftMating

Dear friends,

I made something for you this Christmas. I hope you'll enjoy it!

Each year I have a secret I use to find gifts for people: go to Amazon, find two things I know my gift recipient likes, then compare the "similar items" section to find matches. It's kind of tedious to do, but it works like a charm. Enter computers. Exit the tedious.

This year, I made a website that does the same thing without any effort: GiftMating.com

]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333135 2012-11-05T16:12:31Z 2013-10-08T16:32:53Z Don't re-elect SOPA supporters on Tuesday

As elections draw near, remember that it's not just about the President. We'll vote on a number of Congressional seats too.

If you haven't take a second to get a quick read on your senator and representative, do that now.

As you're considering congressional leaders, take note of who never came to their senses with regard to SOPA, the bill that was going to break the internet. For quick reference, if you're in one of these states or districts, please pay extra attention.

You have a SOPA supporter up for re-election: 

Arizona
Don't re-elect Senator Kyl

California
Everyone: Don't re-elect Senator Feinstein
District 24: Don't re-elect Representative Gallegly

District 27: Don't re-elect Representative Sherman
District 28: Don't re-elect Representative Berman
District 29: Don't re-elect Representative Schiff
District 32: Don't re-elect Representative Chu
District 33: Don't re-elect Representative Bass
District 43: Don't re-elect Representative Baca
District 45: Don't re-elect Representative Bono Mack

Connecticut
District 1: Don't re-elect Representative Larson

Florida
Everyone: Don't re-elect Senator Nelson
District 12: Don't re-elect Representative Ross

District 19: Don't re-elect Representative Deutch
Distruct 20: Don't re-elect RepresentativeWasserman Schultz

Georgia
District 12: Don't re-elect Representative Barrow

Michigan
District 14: Don't re-elect Representative Conyers Jr.

Minnessota
Everyone: Don't re-elect Senator Klobuchar

Mississippi
District 1: Don't re-elect Representative Nunnelee

North Carolina
District 12: Don't re-elect Representative Watt

New Mexico
Everyone: Don't re-elect Senator Bingaman

Nevada
District 2: Don't re-elect Representative Amodei

New York
District 3: Don't re-elect Representative King
District 23: Don't re-elect Representative Owens

Ohio
Everyone: Don't re-elect Senator Brown
District 1: Don't re-elect Representative Chabot

Pennsylvania
Everyone: Don't re-elect Senator Casey
District 10: Don't re-elect Representative Marino

Rhode Island
Everyone: Don't re-elect Senator Whitehouse

Tennessee
Everyone: Don't re-elect Senator Corker
District 5: Don't re-elect Representative Cooper

Texas
District 21: Don't re-elect Representative Smith

Virginia
District 6: Don't re-elect Representative Goodlatte

Notes

Data courtesy of ProPublica
* Some SOPA supporting senators and representatives are not mentioned here because they're not up for re-election or aren't running again.

Please tweet/share with your friends in other locations!

]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333137 2012-09-13T02:30:00Z 2013-10-08T16:32:53Z Visualizing Latency Numbers Every Programmer Should Know

I recently saw Latency Number Every Programmer Should Know and was having trouble getting my head around the scale, so I made this visualization to help me out.

I converted latency times to their equivalent light distances (how far light travels in that much time) and plotted those distances on a map to get a sense of the latency numbers in relation to each other.

Source Data

The smallest few latency times are included here with their respective comparisons.

About me

My company runs "speed interviewing" events over video chat to connect developers and companies for face-to-face conversations. If you're interested in latency and performance, we're hosting a web-event Tuesday and would love to have you participate: Hirelite.com.

]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333139 2012-01-22T21:50:00Z 2014-06-01T01:04:56Z Code, Picasso, and Simplicity

I coded all day yesterday, focusing on a new feature for Hirelite: Speed Dating for Software Jobs. I implemented ~300 lines, added tons of functionality, and was feeling crazy productive. After this surge of productivity, though, the familiar pangs of technical debt anxiety came. I prescribed a hearty dose of refactoring.

I looked for commonalities to refactor among the eight paths of the feature. In particular, two paths stuck out as having more in common with the rest of the feature than the other six. Coincidentally, these two paths were far more commonly used than the others. Additionally, these two paths could effectively cover the scenarios implied by the other six.

Interestingly, these commonalities emerged through implementation. As I implemented the eight paths, the data structures backing each path generally fell in to two buckets. Each of the two more commonly used paths took advantage of different data structures, allowing the less common paths to be covered by one or a combination of the two.

These things weren't obvious from the user experience or product perspective. It took a deep, code-level understanding of the details of the problem and multiple potential solutions to surface this insight.

By the time I actually finished the feature, it was down to 50 lines. Though the simplified solution now seems obvious, I'm sure I would not have found this shortcut without working through the initial cases and writing the 300 lines. 

It always astounds me how much work it takes to understand something well enough to truly simplify it. Sometimes I feel bad, like I've wasted a bunch of time building something that should have been easy from the start. Or maybe I shouldn't have done it at all - I should have hired a rockstarguru who doesn't need to write rough drafts of anything, ever. And then I remember those people don't actually exist.

The same seems to be true for art. Picasso said:

... pictures went forward toward completion by stages. Every day brought something new. A picture used to be a sum of additions. In my case a picture is a sum of destructions. I do a picture - then I destroy it. In the end, though, nothing is lost: the red I took away from one place turns up somewhere else.

Picasso simplified masterfully. In 45 days, he drew 11 bulls, eventually boiling a bull down to just 9 lines.

Pablo Picasso - The Bull. Dec. 5th 1945 - Jan. 17, 1946. Image source and further reading: Pablo Picasso - Bull: a master class on abstract art

Despite all this, I still have this gut feeling that I should have known.

  • Do you run in to situations like this?
  • Any tips on how to shortcut early iterations that take so much time?
  • Is this the type of thing that more experience helps you get around or is it purely a creative process?

After we launch the feature, I'll try to follow up with a deeper dive in to the specifics of the implementation.

]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333141 2011-02-27T21:31:00Z 2015-04-21T13:02:34Z Developers, you are the last line of defense

One of the main reasons all of development isn't outsourced is that it's hard to replace an in-house developer's personal investment in the business, cultural understanding, and market understanding. Additionally, communication is typically orders of magnitude more efficient.

As an in-house developer, you have a clear responsibility to give technical feedback on product designs, but your responsibility doesn't stop there. You are the last line of defense for your company's product or service. If a bad feature makes it past you, it gets released. If you're implementing a feature that makes no sense for your target market, or is spammy, or rubs you the wrong way, it is your obligation to speak up.

There is a natural set of responsibilities and checks for a product company. The management team sets the product vision. The product team specifies the product vision. The development implements the product specification.
There are two ideal outcomes from you defending your product:
  1. You convince the product team or your manager that there's a problem.
  2. Your product team or manager convinces you that the specified solution applies well for your market, use case, or company culture.
Neither situation is bad. In #1, you make them think more about the problem and potentially reach a better solution. In #2, you learn more about your product and market allowing you to better defend your product in the future from poor designs. 

Alternatively, you could learn that your company doesn't accept feedback like this. If that is the case, you are likely undervalued, and your company should probably be outsourcing the work (and likely will in the future). You should start considering other employment options.

Remember, if you release a bad product or feature, it is your fault. "I just built what was specified," is not an excuse for full-time, in-house developers. You build the product, you understand its details, and you release it to customers. It's your duty to defend it.

Self promotion

I run a company on a mission to put recruitment agencies out of business. We host speed interviewing events using video chat where 20 job seekers talk to 20 companies for 5 minutes each. If you're looking to evaluate the software job market or looking to hire, check out Hirelite.com.
]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333143 2010-11-15T15:00:00Z 2013-10-08T16:32:53Z Find a place to hack using NYC architecture

Since starting Hirelite: Speed Dating for Software Jobs, I've been taking a lot of meetings around New York City. After each meeting, I like to find a place nearby to sit, plug in my laptop, and hack for a few hours. In New York, it's hard to find a place you can sit with some elbow room unless you know where to look (Starbucks is usually packed). It turns out, due to zoning regulations, NYC abounds with free public space, often indoors and often with open power outlets where they don't mind you sitting for a few hours.

tl;dr - In Manhattan, look for newish buildings that have a higher base height than buildings around them. Chances are, there's a place you can hack.

[Base height illustrated source]

Example

In the example below, there are three buildings. #2 has a much higher base height in relation to buildings #1 and #3. There's probably a place to hack here.

Why is this?

In the late 1800's and early 1900's, as buildings in New York City were built taller and taller, people protested the loss of light due to the shadows cast and light blocked by new buildings. When the Equitable building was built in 1915, it cast a 7-acre shadow and enforced the need for more zoning regulation.

[The Equitable Building source]

Early attempts to regulate building height, base height, and setbacks (how high building walls may be before they must be set back in relation to the building footprint), including the 1916 Zoning Resolutions, were too restrictive and were plagued with other problems inherent to a growing city.

New regulations were drafted to better fit the city's expansion, culminating in the 1961 Zoning Regulations. These regulations set forth incentives for building developers to create publicly available space. Essentially, the new regulations allowed building developers to build with a higher base height in exchange for having an enclosed atrium, an outdoor park, or some other public space. This is where the hack comes from (the hack doesn't work if there are a cluster of buildings taking advantage of these incentives).

If you prefer to research for yourself instead of finding a place on the fly, just visit this list of of all privately owned public space in NYC. This will also help you narrow down outdoor vs indoor public space.

For more information see: NYC Zoning History.]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333144 2010-09-08T15:00:00Z 2013-10-08T16:32:53Z How To Value Your Startup Using Comparables

I'm embarrassed to admit that lately, I've been watching a lot of HGTV. Whenever I have programming to do that is easy but time consuming, I watch House Hunters or Designed to Sell in the background. On both shows, buyers and sellers use comparable houses to help them put a value on a house. Similarly, investors value companies based largely on how the company compares to other companies they've seen before. Wouldn't it be nice if there was some way for founders to see the valuations of other startups too?

Finding and Valuing Startup Comparables

You can start valuing your company more like an investor by seeking out comparable startups and working backward from the funding they've raised.

  1. Go to the funding section of CrunchBase and look for companies who have received funding recently that are similar to you: similar stage (angel, seed, series X), similar progress (demo, launch, 10k users, paying customers), similar team size/composition.
  2. Take the funding amount, divide it by 0.2 and 0.3 to get a range for the post-money valuation. 0.2 and 0.3 correspond to how much dilution you expect from the funding. Example: GroupMe raised $850k. The post-money (high end of the range) is $850k / 0.2 = $4.25m.
  3. Subtract the funding amount from each side of the range to get the pre-money valuation. Example: GroupMe's pre-money (high end of the range) is $4.25m - $850k = $3.4m.

Here are a few example pre-money valuations of companies on CrunchBase who have received seed or angel funding within a month. Ideally, you'd look closer at the composition of the team and the progress of company; however, I've only included the team size and how long the company has been operating here.

]]>
Nathan Hurst
tag:blog.nahurst.com,2013:Post/333145 2010-07-19T16:00:00Z 2017-01-09T05:56:14Z How Much Equity a Technical Cofounder Should Get

Through Hirelite, cofounders often ask me how much equity a technical cofounder should get. The graphic below balances the risks cofounders take with their relative contributions to help answer this question. All assumptions and clarifications are noted after the graphic.

This covers one of the most common situations I encounter: For a pre-funding web startup whose team includes only a non-technical cofounder, how much equity should an incoming technical cofounder get?

Technical cofounders, remember that the number of shares or options doesn't matter, just your percentage ownership (what the chart shows).

Assumptions

For this case, I assume the non-technical cofounder has already contributed significantly to the business and will likely get more equity (in this chart their minimum ownership is 50%). This doesn't have to be the case. Technically inclined people can definitely build something on their own, and then seek a non-technical cofounder, retaining more equity for themselves. Even if the technical cofounder doesn't prototype something first, they can still contribute more to the business and receive more equity (ex: someone who did marketing for 2 years out of undergrad manages to recruit a top 10th percentile programmer with a successful app in the iPhone app store).

I assume both the non-technical and the technical cofounders are compensated equally. I also assume they are either working on their company full time now or will be soon. Compensation is probably between $0 and a ramen salary. This is an area that varies widely and can significantly impact how much equity a technical cofounder receives (if they take more salary). It's beyond the scope of this post, but I'll try to cover it in the future.

I assume the technical cofounder has a reasonably general set of technical skills and can pickup new technical skills quickly. Ex: they're primarily a back-end programmer, who can code basic front-end specs, and who can administer cloud hosting.

I assume both cofounders will be diluted equally as more employees and investors get involved.

Finally, I assume this chart may be a little surprising to non-technical cofounders. Why should a technical cofounder get so much of the company? Especially a company based on your vision. Basically, it's because ideas aren't worth much. Execution is what matters, and in most web startups that falls on the technical founder. Software developers are a hot commodity right now, and many of them know it, so they're on the lookout for really stellar business people to partner with, not some run-of-the-mill, me-too idea having, 10k foot synergizer without any concrete sales prospects, marketing ability, or product experience. Sorry for the rant, but in all seriousness, I've seen too many good non-technical founders delay building a product for months because they're too stingy with equity.

Other Reading

Here are a few other approaches by others in the venture and tech community. There are no hard rules for this kind of stuff, so I'd recommend reading them and synthesizing with this:

Notes

[1] Technical cofounder starts with 50%: start by assuming the technical and non-technical cofounders will contribute similarly to the business and are taking similar risks for the business. Give the non-technical cofounder extra equity for anything "above and beyond" (see final assumption above for more). Also, here's an example calculation: 50 (base equity) - 10 (for working prototype) - 5 (has over 10k users) - 10 (has raised VC) = 25. The technical cofounder gets 25% of the company.

[2] Working prototype (not just wireframes) -10%: If a non-technical cofounder has a working prototype, they've likely assumed some risk already to build the prototype (perhaps by contracting it out). Creating wireframes doesn't require much risk taking or even really help de-risk much of the busines.

[2a] Has paying customers -10%: If the company already has paying customers, the non-technical cofounder has already eliminated a huge risk for the business; someone wants the product.

[2b] Has over 10k users -5%: If the company doesn't have paying customers, but does have some reasonable user traction (with an nice trajectory), the non-technical cofounder has de-risked the business some, but not as much as having paying customers.

[3] Non-technical cofounder has significant connections or experience -10%: Connections include: relationships with key people in the company's target market, social network connections, blog readership, etc. Domain specific experience within the target market are helpful as are more broad experiences in sales, marketing, product development, or business development (probably on the order of 5+ years outside of undergrad, grad, or MBA school).

[4] Non-technical cofounder has raised venture capital before -10%: The non-technical cofounder has done a startup before, and someone has trusted them with a lot of money. It will probably be easier to get money again. If your business doesn't need external capital, tone this number down, but it's still important (maybe -5%) because it conveys a degree of startup savvy.

[5] Non-technical cofounder has had a successful exit before -10%: The biggest predictor of future success is past performance. This could also apply to non-exit situations where the non-technical cofounder started a company that is operating successfully and the non-technical cofounder has chosen to move on, etc.

[6a] Salary upon funding -0%: No extra equity for getting a salary upon funding. It may not be a market salary, but a technical founder will likely get something if they elect to. Why should a technical cofounder take less equity upfront because they may or may not receive a salary later? In this situation a technical cofounder and a non-technical cofounder are taking similar risks; therefore, neither get any extra equity.

[6b] Non-technical cofounder has idea and vision -0%: This is just part of the job description and included in the non-technical cofounder's initial 50%. Execution is what matters anyway (see final assumption above for more).

[6c] Non-technical cofounder has MBA -0%: (this is my opinion) In the early days of a startup, an MBA doesn't help much. It certainly doesn't hurt, but it shouldn't affect equity.

[7] Non-technical cofounder invests money -5% per $10k: This is an approximation based on a very early stage valuation of $200k. The situation will vary from company to company based on who is involved with the company and what they've accomplished so far. When I think about this, I only include money still unspent when the technical cofounder joins (usually the money was used to build the initial prototype. Sometimes I adjust the equity for the "working prototype" step above).

[8] Lower limit 10%: A non-technical cofounder wants to ensure the technical cofounder has compelling incentives. I consider this the minimum if the technical cofounder is not taking a salary.

    ]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333146 2010-07-15T15:23:00Z 2013-10-08T16:32:53Z Easy local repository browsing for Git or Mercurial

    In both Git and Mercurial, there's a very easy way to browse your local repository in a web browser that I didn't know about until recently. You should really try these right now. They've already made a huge difference for me.

    Browse your local Git repository

    git instaweb --httpd webrick # view at http://localhost:1234

    If you prefer not to use webrick, you could install lighttpd and then just run git instaweb.

    Browse your local Mercurial repository

    hg serve # view at http://localhost:8000


    Both of these tips came from this forrst post and discussion.

    ]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333147 2010-07-13T17:26:30Z 2013-10-08T16:32:53Z Speed Dating for Software Jobs, a web event - Hirelite Blog

    Speed Dating for Software Jobs, a web event

    Our in-person "speed interviewing" events have worked so well that we're expanding to web-based events. On Tuesday, July 27th, Hirelite will host its first web-based event for software jobs and software engineers in New York City.

    Get your webcams and microphones ready for efficient, face-to-face interviews, just like our in-person event but even more convenient. This web-based event will last 2 hours and feature a series of 5-minute interviews with either software engineers or companies. Since you can only get through so many interviews in 2 hours, we're capping attendance at 20 companies and 20 software engineers.

    Click to view large

    Over the next few months, Hirelite will expand to other cities. If you're interested in Hirelite coming to your city, let us know!

    Related Posts:

    Results of a Speed Dating Event for Hiring Software Engineers

    ]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333148 2010-06-04T14:22:00Z 2014-06-01T00:59:33Z Visual Tech Job Board Comparison

    It's hard to determine if a tech job board is worth watching (if you're a job seeker) or worth posting to (if you're hiring), so I made a quick visual comparison of job boards in New York City.

    I used metrics that were easiest to quantify quickly through examining up to 300 recent local tech job posts on each of these sites, so you should definitely consider metrics other than what I've mentioned here (namely what types of job seekers frequent each job board). A few notable job boards are missing due to technical constraints that I didn't have time to overcome while scraping data (Startuply and Monster load some posts using JavaScript, and TheLadders and LinkedIn require logging in). I've tried to be as objective as possible, but I run Hirelite: Speed Dating for the Hiring Process, so keep that in mind.

    A few notes and observations after the graphic...


    What each metric means

    • Cost - the cost of a single post. The life time of the post varies per site.
    • Headhunter posts - the number of posts originating from recruitment agencies as opposed to from companies that are hiring.
    • Typical company sizes - an estimate of the typical size of companies posting to a job board based on the company name, funding stage, salary/equity balance, and other information contained in the post.
    • 20 most frequent words - the words most often used in job posts at a particular job board. Technical note: I used Lucene (and the StandardAnalyzer) to help with text processing and frequency calculations, so very common words (a, the, ...) are excluded. Additionally, some special characters were omitted from words (see observations for effects).

    Observations

    Keep in mind that more (and more random) samples would be ideal, but here are some preliminary observations:

    First, I noticed that "c" appeared much more than I expected. Companies can't be requesting C skills enough to put it in the 20 most frequent words used Craigslist and Stack Overflow! Well... maybe Stack Overflow. It turns out, the tool I used process the text (Lucene) cut out special characters, normalizing C++, C#, Objective-C, and C all to C, thus inflating the frequency of "c".

    The words "you", "we", and "our" appear very high on 37signals, Craigslist, Hirelite, NextNY, and Stack Overflow, but are much less emphasized on CareerBuilder and Dice. Are the job posts less personal or intimate? Does this matter? From looking at the posts in more detail, it seems to correlate with a greater focus on more specific requirements in posts on CareerBuilder and Dice. Note that the word "years" as in "3 years of Java experience" appear in the top 20 most frequent words of CareerBuilder and Dice; however, they do appear in the top 50 most frequent words of all the job boards surveyed.

    I highlighted words in top 20 most frequent word lists that I thought correlated to technical skills or softer skills to observe the relative importance of each, but I don't see any discernible pattern. Additionally, many of the meanings of these words depend highly on their context (requirements section vs responsibilities section vs about the company section).

    Initially, I thought that posts from larger companies correlated with a higher number of recruiter/confidential posts, but then I got to NextNY where many posts for positions at small to medium sized companies are recruiter/confidential posts. Maybe recruiter/confidential posts will appear in high numbers wherever they're allowed? Hirelite and Stack Overflow have policies against posts where the hiring company is not named, but I don't know of any explicit policy on 37signals (though they have no recruiter/confidential posts). Does anyone know if they have a policy about these posts?

    Finally, let me know what you see in the data or if you have other ideas of what to do with this type of data. I'm considering doing some kind of analysis of how typical job post language compares to typical English - I predict probably an inordinate use of "pirate" and "ninja".

    Data (including top 50 most frequent words)

    37signals
    Cost (single post): $400
    Headhunter posts: 0%
    Typical company sizes: generally medium sized companies or funded small companies
    50 most frequent words: we, experience, our, you, web, have, design, team, work, development, business, can, developer, your, who, software, looking, end, ruby, new, rails, project, management, skills, working, us, strong, requirements, about, from, css, well, knowledge, front, things, technologies, jquery, html, systems, php, all, years, use, technology, some, should, projects, javascript, help, has

    CareerBuilder
    Cost: $419
    Headhunter posts: 65%
    Typical company sizes: large companies
    50 most frequent words: experience, skills, management, business, technology, development, job, work, requirements, our, technical, systems, project, information, knowledge, support, must, years, software, data, have, your, team, ability, required, strong, services, security, robert, half, all, working, email, time, us, opportunity, we, sql, contact, developer, more, new, network, industry, design, you, company, system, server, application

    Craigslist
    Cost: $25
    Headhunter posts: 46%
    Typical company sizes: all company sizes
    50 most frequent words: experience, our, software, development, you, we, work, skills, have, team, new, design, business, strong, knowledge, management, systems, web, c, your, java, developer, technical, years, requirements, please, ability, working, applications, environment, job, must, programming, project, all, company, data, time, technology, product, sql, looking, candidates, york, client, solutions, plus, services, from, well

    Dice
    Cost: $459
    Headhunter posts: 51%
    Typical company sizes: large companies
    50 most frequent words: experience, business, skills, development, management, team, work, knowledge, services, technology, systems, project, technical, new, client, years, data, strong, design, java, support, developer, our, you, required, software, information, web, financial, have, description, working, ability, all, solutions, position, application, requirements, sales, applications, company, other, manager, your, must, title, environment, including, york, understanding

    Hirelite
    Cost: $100
    Headhunter posts: 0%
    Typical company sizes: seed stage to medium sized companies
    50 most frequent words: you, we, our, experience, software, team, web, work, have, your, development, skills, new, looking, design, engineer, from, environment, applications, java, years, strong, technology, get, working, plus, senior, about, us, technologies, developers, who, systems, ruby, javascript, can, business, product, platform, people, like, engineering, building, what, want, understanding, technical, other, developer, company

    NextNY
    Cost: $0
    Headhunter posts: 43%
    Typical company sizes: seed stage to medium sized companies
    50 most frequent words: experience, you, we, work, have, our, skills, your, team, development, new, web, product, business, working, strong, client, management, media, from, apply, all, clients, project, online, data, software, ability, looking, design, marketing, can, years, technology, us, time, sales, including, high, company, about, requirements, must, technical, services, environment, who, advertising, please, lead

    Stack Overflow
    Cost: $350
    Headhunter posts: 0%
    Typical company sizes: generally medium sized companies or funded small companies
    50 most frequent words: you, experience, our, we, development, software, work, team, have, c, skills, new, systems, from, web, technology, design, your, knowledge, strong, working, developers, programming, java, developer, looking, applications, environment, years, technical, high, including, code, business, application, management, about, projects, technologies, all, ability, well, requirements, performance, media, engineer, us, science, more, computer]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333149 2010-04-26T17:03:00Z 2013-10-08T16:32:53Z Ctrl-R Searches History and Other Historical Tricks

    These tricks have saved me a lot of time. Many of them I started using after reading this Definitive Guide to Bash Command Line History by fellow Hacker News reader, pkrumins. It includes a much deeper look at history than the quick examples I cover here. 

    Search Your History Quickly

    No more history | grep ... or hitting the up button 20 times. Just open a command prompt, press Ctrl-R, and begin typing a word in your command. As you type, the most recent command matching what you type will appear. To continue searching backwards in the history, hit Ctrl-R again. Then hit the left or right key to edit the command or hit enter to run it. 

    Increase Your History Size

    Once you know how to search your history, make sure your commands stick around for a while. By default, the history size is pretty low, usually only 500. To increase your history size, add the following to either ~/.bashrc, ~/.bash_profile, or /etc/profile:

    export HISTFILESIZE=1000000000
    export HISTSIZE=1000000

    Analyze Your History

    Once you've built up a sizable history, analyze it to determine possible aliases that will reduce typing time. To see the top 30 most used commands, run:

    cut -f1 -d" " .bash_history | sort | uniq -c | sort -nr | head -n 30

    To see the top 30 most used commands including arguments, run:

    sort .bash_history | uniq -c | sort -nr | head -n 30

    Stop Getting Annoyed When You Forget sudo

    I used to get so mad when I forgot to sudo a command, especially a long one. Not any more. To repeat a command using sudo, run:

    sudo !!

    Reuse Arguments

    Say you want to backup a file then edit that file. Here's how you can reuse an argument from the most recent command:

    cp a-very-long-file-name.txt a-very-long-file-name.txt.bak
    vi !^

    Also, you can use !!:N for the Nth argument, !!:N-M for the Nth to Mth arguments,  !!:$ for the last argument, or !!:* for all arguments.

    Self Promotion

    If you're a software engineer with Linux experience in NYC, consider coming to Hirelite: Speed Dating for the Hiring Process tomorrow evening (4/27).

    ]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333150 2010-04-18T04:10:00Z 2014-06-01T00:59:45Z A Delicious Four Years

    I realized I made my first Delicious bookmark just over four years ago. Here's a visualization of my links. It's a decent approximation of what I know.

     

    Update: I switched to pinboard.in after all the Delicious shutdown controversy.

    ]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333151 2010-04-11T19:35:00Z 2014-06-01T00:59:59Z Thread Synchronization Issues & Romance

    Who knew threads and romantic relationships had so much in common? For those of you new to threads, threads (and processes) allow computers to seemingly do multiple things at once, where each thing is a separate "thread" of execution. On a computer with a single processor, the processor spends short amounts of time executing each thread before switching to another thread to execute. On a multiprocessor system, processors execute threads simultaneously, switching between threads when there are more threads than processors.

    For those of you new to romantic relationships, I don't have much advice for you other than: Don't tell your significant other that you're treating your relationship as a series of thread synchronization problems!

    Also, I'm probably perpetuating some stereotypes here. Sorry, it just makes the examples easier.

    Thread Synchronization Issues

    Deadlock occurs when threads cannot proceed because they're waiting on each other.

    Romantic relationship example:
    You and wife have to wake up at 6am to catch a flight. You half-wake-up at some point in the morning and think, "she'll wake me up," and go back to sleep. The problem is, now it's noon, and you've both been thinking the same thing for six hours. You missed your flight due to relationship deadlock.

    Livelock occurs when threads cannot proceed because they're too busy responding to each other.

    Romantic relationship example:
    When was the last time you heard an obnoxious couple talking on the phone? Think back to the end of their phone conversation. It probably ended like this.

    1: Love you. Talk to you later.
    2: Love you too. Bye.
    ...
    both wait ...
    1: You hang up first.
    2: No you hang up first.
    1: No you...

    You're witnessing relationship livelock. Neither person in the couple nor the couple as a whole can proceed because they're too busy responding to each other.

    Starvation occurs when one thread is deprived of resources by greedy or mis-prioritized threads.

    Romantic relationship example:
    You and your boyfriend share a checking account and deposit money into it on the first of the month. You routinely make small purchases every day. Your boyfriend rarely makes purchase, but when he does, he buys something big. After the first of the month, you successfully make your small purchases for a few days, but then your boyfriend buys an iPad. All your attempted purchases are now denied. You're suffering from starvation.

    Race conditions occur when success depends on the order in which threads run.

    Romantic relationship example:
    Your son wants to go bungee jumping with his friends. He knows that each parent requires that he ask both parents for permission. Using a clever turn of phrase, he realizes that he can exploit a relationship race condition to get what he wants by asking the stricter parent first.

    Son (approaches strict mother): Can I go bungee jumping?
    Mother: No, but ask your father.
    Son (approaches lenient father): Can I go bungee jumping?
    Father: Yes, but ask your mother.
    Son: I already did.
    Father: Great. Hope you have fun!

    Thrashing occurs when threads make little or no progress due to the overhead of context switching.

    Romantic relationship example: A couple tries to decide whether or not to get a pet. The argument gets heated. They keep bringing up unrelated topics. Each time a new topic comes up, they spend five minutes on it.

    1: Having a dog would be so much fun!
    2: You would never clean up after it.
    1: What?! I clean all the time.
    ... five minutes later ...
    1: Well at least I don't leave clothes all over the place.
    2: Psh. I'm the only one that ever does the laundry. I can leave my clothes wherever I want.
    ... five minutes later ...
    2: I don't know if I can talk about this anymore. I'm just going to go watch TV to cool down.
    1: You watch TV all the time! We don't even need a pet. You spend all your time with the TV.

    Every context switch gets the couple further away from where they started and from the problem they're trying to resolve. They're thrashing.

    Busy waiting occurs when one thread continuously checks if it may proceed, robbing other threads of processing time.

    Romantic relationship example: A couple is getting dressed for a party. The man is dressed and ready to go. The woman is nowhere near done. The man keeps interrupting the woman to ask her if she's ready yet. The man is busy waiting.

    Self Promotion

    If you're a developer and you like these sorts of problems, consider attending Hirelite: Speed Dating for the Hiring Process on Tuesday, April 27th in NYC where companies will be looking for great software people.]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333152 2010-04-04T19:08:00Z 2017-01-18T18:17:31Z Black Hat Recruiter Tactics

    Since starting Hirelite, where we get companies and software people talking directly, I've heard a lot of horror stories about working with recruiting agencies. When I hear these stories, I can't help but think of black hat vs. white hat hacking and SEO, so I call recruiters who engage in unethical practices "black hat recruiters". Black hat recruiters resort to the tactics below because they're too lazy to confront the real challenges involved in finding and matching good people and good companies. Please note that not all recruiters are bad, and some provide a lot of value, but this post is not about those recruiters. This post is about black hat recruiting where tactics range from lies to ethically gray practices to illegal activity (in approximate order of how common they are):

    Posting misleading job descriptions - This is by far the most common form of abuse. Recruiters will post a job description for a legitimate position for a client, but falsify some of the information to entice candidates. For example, a recruiter will inflate the salary/compensation portion of the job description or inflate the job responsibilities while dumbing down the job requirements.

    Posting bait-and-switch job descriptions - Black hat recruiters will advertise a job that does not exist or is already filled just to receive resumes from job seekers that they can contact about other job opportunities. This is very similar to a tactic that black hat apartment brokers use (mentioned in Rent Hop's comparison of headhunters and apartment brokers).

    Surreptitiously modifying a job seeker's resume - Black hat recruiters often request a resume in a format they can modify. They will make modifications to job seekers resumes without telling job seekers and then give the modified resume to their clients. Modifications range from obscuring contact information so that the recruiter is always in the loop to more liberal modifications like inflating experience and skills. Nothing's worse than getting to an interview and finding out that you know COBOL from the hiring manager reading it off your resume.

    Approaching other companies job seekers interview with - Recruiters often ask job seekers what other companies they are interviewing with under the guise of tailoring their search to the job seeker. Some recruiters will go as far as to ask who specifically the job seeker is in contact with. Armed with that information, a recruiter will contact the other companies and try to send competing job seekers. I've spoken to one job seeker who suspected this was happening and caught their recruiter in the act. This job seeker told the recruiter a friend's name and had the friend wait for the recruiter's call. The friend didn't have to wait long. Only 10 minutes after the initial call ended, the recruiter called the job seeker's friend. The recruiter denied everything.

    Cold calling and pressuring low level employees - Black hat recruiters will call low level employees at a company and threaten termination and legal repercussions unless the employee passes the recruiter along to a hiring manager at the company.

    Buying resumes from hiring companies - Black hat recruiters will give discounts to companies that will pass all the resumes for a particular position along to the recruiter. These resumes could be from other recruiters or from candidates who contacted a company directly.

    Pressuring job seekers into interviews - Black hat recruiters will pressure job seekers into interviews that they don't want to go on. Sure, job seekers should stand up to them and say, "I don't want that job," but when a recruiter responds, "I'm not going to put you in front of <company> unless you go to this interview," job seekers may give in.

    Promising exclusivity to job seekers - Black hat recruiters will promise a job seeker that they will not submit other job seekers for the same position as long as the job seeker agrees not to talk to any other recruiters. The recruiter then submits multiple competing job seekers for a position. If one is rejected, he tells that job seeker that the company decided there wasn't a fit and continues to send him to other companies.

    Recruiting the references of a job seeker - Black hat recruiters request references from job seekers and recruit those references. Later, job seekers hear from their references that their recruiter pressured them for resumes to send to clients, sometimes for the exact job the original job seeker was up for!

    Faking a relationship - Black hat recruiters will hear that Dunder Mifflin, a company they have no relationship with, is hiring. Instead of approaching Dunder Mifflin about working for them, the recruiter will solicit resumes from potential job seekers for exciting new openings at Dunder Mifflin. The recruiter will then approach Dunder Mifflin with the resumes they have. If Dunder Mifflin rejects the recruiter, the recruiter will tell the job seekers that Dunder Mifflin said there wasn't a fit for them.

    Discrediting an employee's current company
    - Black hat recruiters will contact an employed potential candidate and tell them that their current company is in a precarious financial state and offer to find the employee another job. Black hat recruiters will even do this to employees of their own clients.

    Simulating expiring offers - When a company sends an offer to a job seeker, black hat recruiters will tell the job seeker that they only have X days (where X is usually 1 or 2) to accept the offer; otherwise, it will be rescinded. This practice is a bit more rare because job seekers and companies know each others' contact information by this point, but I've heard of this happening to at least one company and one job seeker (separate events).

    Sending false offer letters - Black hat recruiters will send out fake offer letters to job seekers for companies they're having trouble getting interviews for. Black hat recruiters rely on job seekers requesting to interview with the company before accepting the offer. The recruiter then arranges an interview with the company. If the company like the job seeker, the recruiter makes sure to process and negotiate the offer, sometimes issuing a "revised" offer to the job seeker. If there is not a fit for the job seeker at the company, the recruiter is no worse off than they started, and they just drop all contact with a job seeker.


    If you're thinking that any of these practices might work for you, think again. Seriously. They may work in the short term, but you will do irreparable harm to your reputation, the reputation of job seekers, and the reputation of companies you represent in addition to possibly opening yourself up to legal problems.

    If you're a company or a software engineer who's tired of dealing with these tactics, check out Hirelite: Speed Dating for the Hiring Process. We have another event next Tuesday.

    Got any more horror stories? Leave them in the comments.]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333153 2010-03-22T18:54:46Z 2013-10-08T16:32:53Z Results of a Speed Dating Event for Hiring Software Engineers

    On Tuesday, I ran Hirelite's first event: Speed Dating for the Hiring Process for software engineers. Read about how it went here: Results of a Speed Dating Event for Hiring Software Engineers.

    ]]>
    Nathan Hurst
    tag:blog.nahurst.com,2013:Post/333154 2010-03-15T07:17:00Z 2016-12-03T20:17:02Z Visual Guide to NoSQL Systems

    There are so many NoSQL systems these days that it's hard to get a quick overview of the major trade-offs involved when evaluating relational and non-relational systems in non-single-server environments. I've developed this visual primer with quite a lot of help (see credits at the end), and it's still a work in progress, so let me know if you see anything misplaced or missing, and I'll fix it.

    Without further ado, here's what you came here for (and further explanation after the visual).

    Note: RDBMSs (MySQL, Postgres, etc) are only featured here for comparison purposes. Also, some of these systems can vary their features by configuration (I use the default configuration here, but will try to delve into others later).

    As you can see, there are three primary concerns you must balance when choosing a data management system: consistency, availability, and partition tolerance.
    • Consistency means that each client always has the same view of the data.
    • Availability means that all clients can always read and write.
    • Partition tolerance means that the system works well across physical network partitions.

    According to the CAP Theorem, you can only pick two. So how does this all relate to NoSQL systems?

    One of the primary goals of NoSQL systems is to bolster horizontal scalability. To scale horizontally, you need strong network partition tolerance which requires giving up either consistency or availability. NoSQL systems typically accomplish this by relaxing relational abilities and/or loosening transactional semantics.

    In addition to CAP configurations, another significant way data management systems vary is by the data model they use: relational, key-value, column-oriented, or document-oriented (there are others, but these are the main ones).
    • Relational systems are the databases we've been using for a while now. RDBMSs and systems that support ACIDity and joins are considered relational.
    • Key-value systems basically support get, put, and delete operations based on a primary key.
    • Column-oriented systems still use tables but have no joins (joins must be handled within your application). Obviously, they store data by column as opposed to traditional row-oriented databases. This makes aggregations much easier.
    • Document-oriented systems store structured "documents" such as JSON or XML but have no joins (joins must be handled within your application). It's very easy to map data from object-oriented software to these systems.

    Now for the particulars of each CAP configuration and the systems that use each configuration:

    Consistent, Available (CA) Systems have trouble with partitions and typically deal with it with replication. Examples of CA systems include:
    • Traditional RDBMSs like Postgres, MySQL, etc (relational)
    • Vertica (column-oriented)
    • Aster Data (relational)
    • Greenplum (relational)

    Consistent, Partition-Tolerant (CP) Systems have trouble with availability while keeping data consistent across partitioned nodes. Examples of CP systems include:

    Available, Partition-Tolerant (AP) Systems achieve "eventual consistency" through replication and verification. Examples of AP systems include:

    Self promotion and Credits

    • If you're a developer and looking for a job or if you're hiring developers and these data systems are important to you, consider coming to Hirelite: Speed Dating for the Hiring Process on Tuesday.
    • This guide draws heavily from a recent Ruby meetup (by Matthew Jording and Michael Bryzek) and a recent MongoDB presentation (given by Dwight Merriman).
    • Thanks to DBNess and ansonism for their help with validating system categorizations.
    • Thanks to those who helped shape the post after it was written: Stan, Dwight, and others who commented here and on this Hacker News thread.

    Update: Here's a print version of the Visual Guide To NoSQL Systems if you need one quickly (warning: it's not all that pretty and I may not keep it updated, but as of 3/17/2010, it's current).

      ]]>
      Nathan Hurst
      tag:blog.nahurst.com,2013:Post/333155 2010-03-03T14:27:00Z 2013-10-08T16:32:53Z Why Networking Sucks for Introverts (and one way I'm trying to fix it for us)

      Networking can really suck for introverts. I know because I'm one of them. You're probably thinking, "Of course! Introverts are shy and have trouble with social interactions." However, introversion is much more complex and encompasses an overlapping spectrum of feelings. Here's my take on it:

      In general, the terms "introvert" and "extrovert" describe social preferences, not social capabilities, and it's important to remember that there's nothing wrong with tending toward one side or the other. Both have advantages and disadvantages (many that you can overcome with practice or adrenaline).

      Problems that Introverts Have with Networking

      These observations stem largely from the software-related meet-ups I've attended in NYC (Hackers & Founders, Hadoop, Android, etc), so they may only be applicable to technically-oriented introverts.

      1. Making small talk

      "The weather sure is ____." When introverts hear this, we immediately disengage. It's a struggle for us to realize that a little upfront investment in small talk can lead to a great conversation. Small talk is all about finding something to have a deeper conversation about, but often times, introverts get stuck in small talk ruts or completely blank on what to talk about, leading to awkward pauses.

      2. Inducing awkward pauses

      I've been a party to plenty of awkward pauses, both on the "caused" and the "affected" side. Awkward pauses happen for two reasons: struggling with turn taking or blanking on what to talk about. Blanking on what to talk about can happen because introverts have other interesting ideas we're mulling or we've run out of conversation topics. In the past, I've thought about keeping notes on conversation topics, but it's pretty weird to see someone whip out a notebook in the middle of a conversation, so I haven't done it.

      3. Politely leaving conversations of no interest

      If an introvert can't get out of the small talk stage or genuinely has no interest in the person they're talking to (imagine getting stuck talking to a someone from a recruitment agency that snuck in to a MySQL meetup), the conversation is over. Time to escape.

      The polite introverts needlessly stick with the conversation, trying to think of a way to break it off nicely. From personal experience, these dreaded conversations can last up to half an hour. All the while, you're catching bits and pieces of interesting conversations all around you.

      The less polite introverts either have "I don't care" plastered across their faces or just walk away. I have seen both. The latter is much more entertaining.

      4. Having group discussions instead of 1-on-1 conversations

      If there's a type of conversation that introverts love, it's 1-on-1 conversations. It's nerdy, but it's great to get into an intellectual property debate with one other person. However, at most "networking events" it's tough to get a 1-on-1 conversation. Often times you're stuck with a group.

      Introverts have a lot of trouble with group conversations. We feel like we can't get a word in - other people are always talking! We feel like we have to keep up with the main conversation and all the little side conversations that keep splitting off. And a lot of times, it's hard to even join a group conversation.

      Joining a group conversation is hard because everyone already involved is participating in the conversation. It's hard for them to include someone who has just popped in. It sounds strange, but I've seen people walk up to a group conversation, stand there for 10 minutes, and then walk away without ever saying anything.


      What I'm doing about it

      I've resolved to help fix these problems for a subset of introverts in a subset of networking situations. I want to help software engineers, who are definitely more introverted than the general population, network to find jobs and meet companies. To accomplish this goal (and others - a subject of another post), I'm introducing Hirelite.com: Speed Dating for the Hiring Process.

      At a Hirelite event, software engineers will go on 5-minute "speed interviews" with companies. Making small talk and creating awkward pauses will be less of an issue because the conversations will be short and focused on how each party can help the other. Starting new conversations and politely leaving conversations of no interest will be of little concern due to the 5-minute time limit and rotation to the next conversation. And group conversations will be minimized: one company (possibly two people) speaking with one software engineer.

      Hirelite is having its inaugural event on March 16th in New York City. For this event, there is only space for 20 companies and 20 software engineers, so let us know early if you would like to attend.

      ]]>
      Nathan Hurst
      tag:blog.nahurst.com,2013:Post/333156 2010-02-21T18:09:00Z 2013-10-08T16:32:53Z Time to reset some passwords

      About once a year, I accidentally type my password into the user name field on a login form and click submit. Immediately, I realize what I did as I see my password sitting there, mocking me in plain text from the user name field. I did that today, and it's time to go reset my passwords. For those of you who aren't involved in web development, let me explain why.

      Nearly everything you do online gets logged, but it's standard security practice to filter passwords out of the logs. However, filtering passwords doesn't help much when you type your password in a user name field. Here's an example log of what I just did:

      Processing UserSessionsController#create (for 72.14.204.99 at 2010-02-21 11:43:21) [POST]
        Parameters: {"user_session"=>{"user_name"=>"Th1s1sMyP@ssw0rd","password"=>"[FILTERED]"}}
       
      [User Load (0.4ms) incorrect user_name or password - user not loaded]

      Processing UserSessionsController#create (for 72.14.204.99 at 2010-02-14 11:43:53) [POST]
        Parameters: {"user_session"=>{"user_name"=>"nathan","password"=>"[FILTERED]"}}
        [User Load (0.4ms) "user_name"=>"nathan" loaded]

      As you can see, on my first login attempt, the log contains my password as the user name, my IP address, a time stamp, and a note that the login failed. On my second login attempt, the log contains my real user name, my filtered (correct) password, my IP address, a time stamp, and a note that the login succeeded.

      Given that these two events happen within a minute of each other and come from the same IP address, a savvy attacker with access to the logs (or an unscrupulous systems administrator) could determine that my password is Th1s1sMyP@ssword just by looking at the logs. That attacker could also create a script that would prune the logs for all failed logins from the same IP address that are followed by successful logins within some short time period from a different user name. If the attacker slurped the logs into a database (and had a SQL-wielding DBA wife to help with his queries like I do), he could use a query like this:

      select success.ip, success.user_name as user_name, fail.user_name as password
      from
          (select *
              from login_attempt f
              where f.success = false
          ) fail
      inner join
          (select *
              from login_attempt s
              where s.success = true
          ) success
      on fail.ip = success.ip
      and success.datetime between fail.datetime and date_add(fail.datetime, interval 5 minute)

      on a login_attempt table with columns: ip, datetime, user_name, and success to give him possible user name/password combinations.

      Luckily, I only have to change the passwords for 2 or 3 accounts, but many web users carry a single password with them to every site, leaving them broadly exposed if an attacker discovers the password for a single account.]]>
      Nathan Hurst
      tag:blog.nahurst.com,2013:Post/333136 2010-02-11T04:33:00Z 2013-10-08T16:32:53Z YourTinnitus.com launches this week

      Do you know the high pitched sound you hear when a TV is on but muted? Imagine you heard that noise constantly... and really loudly. That is tinnitus: chronic ringing in the ears. Currently, 12 million Americans suffer enough from their tinnitus to require medical attention, and 2 million patients report being unable to function "normally" day-to-day. Tinnitus can even be so extreme that it drives some sufferers to suicide.

      There is currently no cure for tinnitus. Though there are ways to diagnose, monitor, cope, and potentially inhibit tinnitus sounds for tinnitus sufferers, primary care physicians rarely have the training or equipment to deal with tinnitus patients, and specialists are hard to come by. With this lack of viable medical options, two camps have sprung up: online pill pushers and high-end devices manufacturers (in the $5k range). This is where we come in. YourTinnitus.com offers an option to help tinnitus sufferers diagnose, monitor, and learn about their tinnitus. We do nearly the same thing that the $5k devices do, except we do it online for about 1/100th of the price.

      After a few great months of working with the auditory neuroscientists in the Department of Psychology, Neuroscience, and Behavior at McMaster University, we're proud to release YourTinnitus.com this week. With our tools, tinnitus sufferers will be able to objectively evaluate if their tinnitus worsens or improves over time, determine how similar their tinnitus is to others who have tinnitus, and download a sound file of their tinnitus that they can let friends, family, and doctors listen to to prove they're not crazy. Over the next few months, we'll be working on even more tools to evaluate, diagnose, and potentially mask tinnitus sounds for tinnitus sufferers.]]>
      Nathan Hurst
      tag:blog.nahurst.com,2013:Post/333138 2010-02-02T06:20:00Z 2014-06-01T01:06:32Z Email server recipe for avoiding spam filters

      Setting up an email server and making it work with anti-spam protocols is one of those things that's 100x easier to do the 2nd time around. I follow these steps whenever I need to do it.

      Prerequisites

      • Apache
      • Ubuntu 9.04 (these instructions should work for other versions, but that's what my target currently is)

      Ingredients

      • postfix
      • dkim-filter - DKIM (DomainKeys Identified Mail - new standard)
      • dk-filter - DomainKeys (legacy protocol - needed for Yahoo, etc)
      • SPF records

      Postfix Setup

      First, we need to install an email server, postfix. I'm going to skimp a little on configuration here because with most EC2 AMIs I use, postfix is already installed. For more information see: Postfix setup and configuration for Ubuntu.

      The most important parts are installation:
      sudo aptitude install postfix

      and configuration of myhostname, mydomain, and mynetworks (which determines which hosts may send mail through the server). Here's the section from a sample configuration:

      myhostname = yourdomain.comalias_maps = hash:/etc/aliasesalias_database = hash:/etc/aliasesmyorigin = /etc/mailnamemydestination = yourdomain.com, localhostrelayhost =mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128mailbox_size_limit = 0recipient_delimiter = + inet_interfaces = allmydomain = yourdomain.com

      DKIM setup and configuration for Postfix and your DNS

      Next we need to install and configure DKIM. This will make the server sign email headers so that users can assert, through DNS, that an email's origin has not been forged. It's safe to directly follow the instructions here: DKIM setup and configuration for Postfix and your DNS. The only catch may be with your DNS; as some DNS's (particularly GoDaddy) will not display the fully qualified TXT record name. If you enter "mail._domainkey.mydomain.com" your DNS may show the record name as "mail._domainkey". If it does, don't worry about it. It's just following an internal convention. When the DNS server receives queries for "mail._domainkey.mydomain.com", it will respond correctly.

      DomainKeys setup and configuration for Postfix and your DNS

      DKIM (described above) is the newer, standard protocol for signing emails; however, some mail providers are still using the older DomainKeys protocol (namely Yahoo). It's safe to directly follow the instructions here: DomainKeys setup and configuration for Postfix and your DNS, but watch out for a few repeats. You will have already completed the second part of the "Configurating DNS" section, and should use the second form of the Apache configuration in the "Startup and testing" section because you will have already placed a DKIM configuration in Apache:

      milter_default_action = acceptmilter_protocol = 2smtpd_milters = inet:localhost:8891,inet:localhost:8892non_smtpd_milters = inet:localhost:8891,inet:localhost:8892

      SPF setup and configuration for Postfix and your DNS

      SPF (Sender Policy Framework) allows mail recipients to reject mail received by senders who DNS does not recognize as authorized senders for a domain. It's safe to directly follow the instructions here: SPF record setup and configuration for Postfix and your DNS, though you may need to create the "smtpd_recipient_restrictions" section in your postfix configuration.

      Validating your installation

      Throughout this process, you can emailing check-auth2@verifier.port25.com to Validating your email server configuration. You will receive an email reply to the address you sent the check request from. Also, make sure that the email address is from the domain you are targeting (it could be different based on the hostname or other postfix configuration, particularly on EC2). Here's an example command to send the email from your server:

      echo "test message" | mail -a "From: you@yourdomain.com" -s test check-auth2@verifier.port25.com

      Other limitations

      From time to time, you may run across an email sending limit imposed by EC2 and you may need to request that the limit be removed.

      Additionally, it's good to check that you are not listed on Spamhaus.]]>
      Nathan Hurst
      tag:blog.nahurst.com,2013:Post/333140 2010-02-01T04:21:46Z 2013-10-08T16:32:53Z Choosing Posterous over Tumblr After a semi-thorough comparison, I'm choosing Posterous over Tumblr. Initially, I wanted to pick Tumblr for no reason other than it being in NY and being funded by Union Square Ventures. However, I chose Posterous because of it's:
      • compatibility with how I write - The easiest way for me to sync post writing across my desktop, laptop, and phone is to save drafts in gmail. It seems like the Posterous team had this specific use case in mind for their product.
      • orientation toward longer-form posts - I need a place to ramble, and to me, Posterous has a look and feel that lends itself to longer posts.
      • focus on content creation - Tumblr seems like it's based on sharing other content, which is fine, but not what I'm going for with this blog.
      ]]>
      Nathan Hurst