Also, to answer a couple questions you will inevitably have while browsing through their comments or old posts:
1) There is a karma threshold for down-voting (currently 500).
2) The "expired link" page you see is a known issue and is unlikely to be fixed any time soon.
As for guidelines:
Always try to add to the discussion. Be nice. This isn't reddit (humor is fine, but stupid jokes are not). Upvote on quality of content, not appeal of content.
Also if you want to search with more control than Google provides, check out:
* Paypal IPN * Stripe * 2Checkout * Dwolla
I'm currently spending a lot of time at Udacity. CS101 was the first resource for learning python that I've been able to through start to finish. (Think Python is second place for me, also very good)
The one area that I still find lacking in on-line learning is math. I can't seem to find anything that's concise, interactive and effective. (Paying is not an option.)
The trick is how to make it every month. On these sites, your reputation will either help you or kill your business.
Looking at your profile, there's no link. I'd suggest linking to your homepage and generally maintaining an active profile on at least Twitter and GitHub, and preferably some personal projects of the kind of thing you want to be paid to build. Anything like that will stand out when contract providers are looking to hire, given that self-reported work history is dubious.
You can split the product intro email and the personal intro from the CEO email, by the way. Stagger the CEO email by a bit and deliver it as text only, and many users will perceive it as if the CEO had just mailed them personally.
I saw you signed up for the free trial the other day. My name is Patrick and I'm the founder of the company. Drop me an email any time if you have a question or need anything.
I know one guy who puts "Sent from my iPhone" on it but that strikes me as being more aggressive than I'd care to do. (If you don't like the "I saw you signed up for" verbiage then a) email this email to yourself, rather than to them, and b) copy/paste the text into a new email to the email address called out at the top. Then everything is literally true again.
Subject: Your insights?
I think you signed up a couple weeks ago now...
How has your team been liking InVision so far? Any new ideas on ways we can make our product even better?
Write me back, I would love to hear from you...
P.S. Did you know about the UX Toolkits section? You can download a bunch of totally FREE high quality UI widgets and stencils -- and we're adding new ones all the time. Check it out: https://projects.invisionapp.com/resources/
Thanks!-- Clark Valberg
I hope all is going well with you! I'm super excited to share the news about a big new Buffer feature. You'll now be able to track analytics in real time for each of your social media posts to know exactly how much impact they have had.
The following analytics are in your account now:
For your Tweets: number of clicks, retweets, mentions, favorites and reach.For your Facebook posts: number of clicks, likes, comments, shares and reach.For your LinkedIn posts: number of clicks, likes, comments and shares.Check out this blog post to get more juicy details about how the new Buffer analytics work.
It'd be awesome get any thoughts you have on the new real-time analytics feature or how you use Buffer in general. Just hit reply to let us know.
- Joel and the Buffer Team
P.S. The whole Buffer team (check out this picture of us! :)) is sitting here and we are waiting eagerly to hear about your thoughts and ideas. We'll be around to answer all your emails for the next few hours. Drop us a line!
- from the team- they are sticking around after sending the email to answer requests - New feature description is short and sweet
I'm Joel, the founder of Buffer. Thanks so much for signing up.
It's probably not every day you sign up to something new so I want you to know that my team and I are here to make you happy, 24/7.
You should try out our awesome browser extension. It'll help you share amazing content to your friends and followers twice as fast.
Let me know if you have any questions or suggestions!
Have an awesome day.
P.S. You can catch me sharing interesting content on Twitter, @joelgascoigne and the team and I usually respond to emails within a few hours.
I am a PHP developer and I ran into this question recently. At the startup where I work, we have a web app that is completely Ajax driven. When we decided to convert those Ajax endpoints to an API to be used with a mobile app and possibly open it to the public, I did some research and eventually decided on node.js and Restify. One of the draws is that with an Ajax webapp, we already have a team of JS devs on staff, so there would be less of a learning curve. I'd suggest looking into it.
EDIT: I forgot to address the multithreading part. I believe that node.js is not true multithreading...it is event driven, so it can use a single thread more efficiently, which should achieve the same effect.
As far as i know that line is automatically false. Yes you can use django for returning html and json(django-tastypie for example).
Also please put more info in the title.
My opinion: There's almost always some $ threshold above which it makes sense to take on a freelance job. Choose your threshold and make it clear to any recruiters. It's always worth keeping good relations, as you say.
Don't forget, that even though they can be annoying and a bit out of touch with what position reqs actually are, they're human too, and a little short but polite response about your situation can go a long way.
Firm politeness never hurts. But it has to be firm.
I usually say 3 months - but it depends on your confidence.
* Ask tons of questions. Not questions for the sake of questions but relevant, interesting questions.
* Get to know people. It's never too early to start networking and you'd be surprised how likely it is that you'll cross paths with some of these Googlers further down the line.
* Pay attention and work hard. A good work ethic is unfortunately a rare commodity. Showing a willingness to get your head down and get stuck in won't go unnoticed.
With that in mind, there are several ways that one can stack the deck against one's self. Morbid obesity, poor personal hygiene, vampire costumes, and, yes, visible tattoos can all serve the purpose of closing a door that might otherwise be open to you.
The questions you need to ask yourself are how important is it that all possible doors remain open, and whether you're in a position in life where the occasional closed door leading to an environment you don't want to inhabit might actually be a good thing.
And of course, the big question. Is there even the smallest possibility that several decades from now your life, values, opinions, career, etc. will have evolved to a place where you find it really really inconvenient to have a marker of the social situation and personal biases you happened to have at age 19 permanently stamped onto the back of your neck.
I certainly wouldn't want that guy in charge of my tattoos today.
At some point soon, you'll mature and get older. And you'll realize that faded, unintelligible blob of ink really isn't that important to who you are.
And people will judge you. It hasn't really hurt me a whole lot in life, but I definitely had to jump over that initial hurdle of "I'm not a threat" again and again.
A few years ago, I showed up for an interview in a suit, tie, and wingtips. A coworker hired about the same time, showed up for his in tee-shirt, baggies, and Teva's.
He was a better fit for the corporate culture and stayed for seven years. I left after about a year.
On the other hand, in the US, either get it, or don't. Making a big deal and asking permission is a sign of weakness.
The view I take is if someone has such hostility towards my tattoos that we can't work together, we probably shouldn't be working together anyway. (Tattoos to me are representative of my life story and are given a lot of thought/designing)
I am happy and I consider myself successful.
It depends on what you mean when you say "curtains for your career" I would imagine.
I would have a look at "The UX Book: Process and Guidelines for Ensuring a Quality User Experience" by Rex Hartson & Parha Pyla. I picked it up on Safari Books a few weeks ago; it really gives you an in-depth look at both the theory and processes involved in UX design.
Also, have a look at the diagram on this page: http://uxdesign.smashingmagazine.com/2012/08/29/beyond-wiref... I have it pinned to my cubicle wall.
1. Memory Management - Java takes care of it all for you, whereas in C++ you have to manually allocate and de-allocate memory, otherwise you will have memory leaks.
2. Learn the Standard Template Library (STL). C++ has a much smaller library of pre-built code that Java. The STL is very good for some basic data structures like map, set, etc.
3. Pointers - Java has references, C++ has pointers. You need to learn how to use them safely.
4. Polymorphism - Similar to Java but syntax is a bit different
5. Operator Overloading - You can redefine operators such as "+" or "-" to make your code look cleaner. This can be dangerous, but very useful if done correctly.
I think that is a good start. Overall the transition to C++ should be relatively easy once you master memory management and pointers.
I was in a similar situation just lately. The above are some very good introductory stuff I found very useful.
For our company, we don't develop internal tools for any given problem until it's a real pain. You'll know when it's an actual pain (as opposed to just an idea), because you'll keep seeing it crop up in your day-to-day work, and if you talk about it with others on your team, they'll say, "Yeah! I know exactly what you mean, I was thinking about that the other day."
We wait until it's a real pain for a couple reasons:
1) We want to make sure we're not wasting our time; we're mostly engineers, and we all get real, unadulterated enjoyment from building things. It's only too easy for our enjoyment and enthusiasm for building a solution to fool us into thinking there's a problem. But usually, if everyone on the team is instantly excited about the prospect of solving some problem, that's usually a good indicator that it's a real problem.
2) The longer we can put off something, the more information we'll have when we go to solve it. In other words, we give ourselves time to figure out first how we want to work, and then find or build tools around that, rather than trying to fit our system to some tool.
The second reason is really important too, because when we sit down to really think about every facet of a problem, how it affects our work and how we have been putting up with it and working around it, we'll often realize the best solution isn't some new piece of software; it's merely leveraging some tool we already have slightly differently.
For one example, we started losing feedback and updates in email, because some person on the team would get left off the email (e.g. someone hit "reply" instead of "reply-all"), and we wouldn't realize it until some task went un-resolved for several days. We could have built or implemented some sort of support desk system and made it the clients' responsibility to make sure tickets are submitted and then integrated it with email. Or, we could just create a unique email alias for each client, which copies everyone involved. The latter took 2 minutes and improved communication threefold.
If you keep growing, you'll eventually reach a point where anything less than a full-blown software solution just isn't going to cut it. But by that time, you've seen how the team deals with the problem over time, and all the pitfalls of other smaller or less-custom solutions, and you'll be able to build the most awesome solution possible.
Rule of thumb: do it manually three times before automating it. That way, you'll have a fair idea of what it is supposed to do (which is the hardest part); you know whether it's predictable enough to be automated; and an how often it will come up.
A programmer is someone who takes 5 hours to automate something that takes 5 minutes
When I first started working at my job I sneakily built a suite of tools for visually working with NL grammars (instead of just buckling down and writing the grammars). Although I don't maintain it anymore, it's now used by an entire team. It was great that my then-managers saw that I was on to something and let me obsess about it for a few weeks.
I recently spent a few weekends writing static code analysis tools to analyze our codebase. There is some pretty exciting stuff that can be done there. It hasn't paid off quite yet, though I know it will.
Another project I've been juggling with my 'official job' is a nice new logging system with all kinds of cool features. There are so many challenges about making a piece of infrastructure work technically and culturally across a large team, however. It's much easier to estimate how long the technical part will take.
I've also written a bunch of tools that just failed to find any real use. In retrospect, these were mostly vanity projects of some kind, whereas the projects that have worked have always been about scratching an itch that I can see other people have (whether or not they articulate it).
I wad the unfortunate administrator for a large virtual mail system in the uk which was run off exim and flat files across 50 machines (one per client). This took 3 guys full time to manage as the machines were all over the uk and needed regular maintenance. I centralized everything and moved it to two virtual postfix machines backed with postgresql and wrote a web interface and set up scripts for backup and administrative operations, including integrated dns management.
Now, 12 years later, these guys are one of the larger hosting companies in the UK...
Automation almost always pays off, but not how you anticipate in some cases.
1. Tools are one of the few institutional advantages that are in the domain of the programmer (rather than the MBA or the sales force). There are many shops out there that suffer from a lack of technical leadership and compete on the basis of (absolutely incredible!) strength of the sales force. Software developers don't win at that game.
They can, however, win at having the best tools. You have to have some unfair advantage, and in most developer-run studios, tools are easier to cultivate than sales methodologies.
2. Customer-facing tools provide customer-visible value. If you're writing error-reporting software that helps debug issues on customer systems, that's providing visible value. If you have client dashboards that show the status of their project and predict ship dates, that's visible value. If your network protocol is faster than REST for your vertical, that means faster software, and that's visible value.
It's all about giving your customers something to hang their hat on to select your shop. If they are getting "good vibes" from the other sales guys, but your software automatically builds them a Powerpoint deck of the project status to present at the weekly update meeting, then there's some class of customers who will prefer working with you, and you are better insulated from competition.
3. If you and your competitors don't do tool investment, then all the boats will rise at the same speed. But if you are doing tool investment, your boat will rise faster. At some point you can do the same job and provide better value than anyone else. When people figure that out, your competitors are forced to first, cut prices to remain competitive, and second, raise expenses to try and achieve tool parity. But you've already got a long head start, so they will either run out of money, license the tools from you, or just focus on the more sales/MBA-receptive customer base, and shrink to a niche offering.
4. As I've hinted at, tools can be valuable and can be licensed to other shops. The only way to really get out of the client "rat race" is to become a product company. Tools are an easy way to make that transition; you have a built-in customer base and an intimate knowledge of the problem domain.
Possible "internal tools" that come to mind are:(1) Analytics(2) CRM-y stuff for the sales and support people(3) Deployment and testing stuff for technical people(4) CMS-y stuff to enable non-technical people to experiment with, or even implement, things that are client-visible. And for technical people to do so more efficiently.(5) Backup, redundancy, disaster recovery etc
If none of these seem more important than others, I guess you need to ask: where is the business now? Where will it need to be in <x> months? How are we getting there? What are the pain points? How can the above improve this (versus implementing new features)?
One cherry-picked example: should technical staff time be spent on improving sales? If sales are your company's limiting factor and you don't have enough salespeople, making them more efficient is really important. If you're still in a soft launch-ish place, then it's not. If you have enough salespeople but not enough leads, maybe mining your own data, or public data, could produce some.
Throughout our massive amounts of failures, we've learned some things (and some things the hard way): there are basics, and there are nice-to-haves. Get the basics right.
Our basics include an entirely zeroMQ based service-oriented architecture (after 8-9 different iterations over the past 4 years). We spent a lot of time writing a ZMQ based DHT, and service wrappers (kinda like zeroRPC). Other basics include a standardized front-end A/B testing based off genetify, email service (with AWS' SES), paypal service, our fair matching services and many others.
The one thing to note is that these basics didn't come overnight though. It came through many many iterations of different products that failed. We merely picked up the components that worked best.
There were things that were nice to have like automated testing and deployment options that we considered. Even using tools like Puppet and/or Chef, we determined, were not quite a good use of our time, considering our release schedule isn't all that crazy, and deployments can be managed by one human being.
But our situation does not apply to you. You need to think about what fits your situation, and your styles. Maybe you are the kind that pushes a release to production servers every 5 minutes. Then yes, having an automated test and build system would be extremely useful.
Start with simple stuff like crons and tiny scripts. Let your internal tools evolve on their own. Don't jump in to write massive automation for your systems. Instead, do it in small parts, just enough to help you.
Hope this helps.
you could spend all your time building these, and still just have scratched the surface.
I think there is a danger in trying to make your own life too easy at the expense of making your customers lives easier - especially during a startup period.
I think for tools you have to just do the math. If it takes you 10 minutes once a week and the tool you build takes three hours to develop - then the effort will start paying off in 18 weeks. If it takes you 8 hours to build the tool the you don't break even for 48 weeks (almost a year).
There could be other reasons to build a tool, though. For example the process is error-prone and a tool will ensure it is done properly. Or it enables a non-tech staff to take over something that allows them to help customers better.
Lastly one task is always worth automating - that is data backups.
As Napoleon said: l'intendance suivra, which means that short term and ancillary problems will be solved anyway.
Another way to say this is that if you keep the general long term direction, it will be ok to use dirty hacks to fix in fee minutes the short term problems, you will know how to do it in a way that we'll not hinder the long term path.
But make sure your tools and automation are really in line with the long term direction.
For example, building a chrome plugin to speed manual testing of a web app would be wrong, architecting it to be fully unit testable would be right.
You'll know when you'll need to build better automation to your product; there won't be enough time to get everything done in a day.
That said, there's a downside to following this approach. When you will need to build automation tools you'll be conflicted with spending your time on automation or on improving your product. Improving your product directly provides benefits, tools indirectly provides benefits. It can be sometimes hard to convince yourself or others that you need to spend x% of your time on internal tools.
Where I work we're at a point where automation is very important. As the CTO of the company I constantly have to challenge the CEO and others that spending money on tools will give us some benefit in long term. The rule (or high level design pattern) that we are trying to implement is for every module of our product, there is a tool to understand the data better for debugging purposes (e.g. a UI to see what step in the workflow the process is in and/or what errors happened, etc), and if data is generated, there's an API/Service to get the data out easily.
However, there is another important aspect in developing internal tools. In a lot of setups, developers rarely have a chance to investigate new technology, new development approach, different architecture, even different programming language on a day to day basis. Work is mostly done using predefined set of technologies.
For tools, the technology requirements are almost always much more relaxed, so the developers themselves gets to choose and try different approaches. While not every tool might end up being success in strictly measured time/money saved sense, in the long run it will help developers stay up to date with the technology, and even apply lessons learned in the real/product development.
As a bonus, employee retention might improve as people won't get bored so soon if they have a chance to try doing something new from time to time.
I work at a university developing research software (primarily - some is also external customer facing). My customers are internal customers, thus profitability and other business measures are not directly my concern.
The biggest issue I face with this is that my customers are non-technical people, so if I were to tell them that our infrastructure is now software defined and I have implemented analytics that will allow me to optimise the caching layer, they will most likely look at me with a puzzled expression and perhaps wonder what I'm actually doing since those things don't provide direct value to them.
The types of internal tools I am thinking of are things like; analytics, automated deployments, CI server etc.
One comment suggested I do a simple calculation like any other business decision. This is something I cannot for the life of me work out how to do. Internal tools will increase my efficiency in the future, so I guess at best I could estimate a payback time for some of these tools (like automation). Even so, how short a payback makes it worthwhile? For other tools, like analytics, how can this type of calculation be made?
Additionally, there are some things that are the "right way" to do things, such as software defined infrastructure vs managing it manually (which I currently do). Investing time in this won't have any immediate payback, but is nice to have in place in the case of a large failure when I need to recover quickly. These types of value calculations for me are not easy to make.
sourthyme, I like the idea of spending one day a week working on this stuff. Perhaps I need to have a conversation with my bosses/customers about this and try to explain to them the value that internal tooling will bring.
Thanks for the answers so far, please keep them coming.
Would adding better analytics allow you to convert more prospects? Sounds pretty important for getting business, despite it being an internal tool.
If you're pre-revenue, or pre-sustainability, all your efforts need to depend on becoming sustainable. Otherwise, you're making a great product for nobody.
I always suggest a digital assistant first. Pay $4-10 an hour and let someone else do it. Wait until that cost becomes a thorn in your side.
It is incredibly important to get your tools right so you can operate as efficiently as possible. At my company we didn't get around to this till much later, partly due to the dilemma you mentioned abt focusing on customer-facing software vs. internal tools, and partly due to the fact that the people who would benefit the most from automation (e.g. finance folks, inventory managers, etc) don't have the same obsession with automating away mundane tasks like us engineers do.
This lack of tools hurt us quite a bit once we started scaling, in ways that impacted some customer relationships (because occasionally we didn't invoice or ship correctly, etc). We have since invested significantly in tools, but we should've done this to begin with.
To make the customer vs. internal tools compromise easier, you may even want to get some basic tools in place via contract work/offshoring and then revisit these later once you have the time/resources. The hard part really is determining what to automate, and how much, and those are decisions that you should make. The development itself can be done by someone else.
Of course internal software MUST be developed using the same quality standards as your frontend program (VCS/tests/code review/etc).
The problems seem to originate from two things; first people often judge their own 'worth' by comparing their work output to others, and two, people who don't understand the details of a particular job seem to think it is much easier to do than it really is.
So in the first case person A, who thinks highly of themselves, and very poorly of a co-worker person B, finds that the co-worker is getting more compensation than they are. This triggers a management issue where someone has to explain to person A the discrepancy. There are a number of real explanations (like Person B is actually doing a harder job and/or providing a more valuable role) that Person A, may be unable to accept.
Or person B may have a role that is significantly different, like they are in marketing (vs engineering) or finance or analysis. Can you compare salaries for someone who cranks out a thousand lines of code a day with someone who can tell you precisely which of those lines of code are making the company money and which ones aren't? Both are great skills, that latter is harder to find, you might pay them a bit more. But explain that to the person writing code? Not easy.
When I was at Google it was proposed a number of times (by engineers) that everyone's salary should just be part of the info available. They didn't do that, but I could see someone like the 37Signals folks or some startup doing it from the start.
I've not worked at a company where that was the case so I can only speculate on what it might be like. For folks who were internally OK with their own perception of self worth it wouldn't matter, for the sociopaths it would give them a new game to 'win', for folks who were not OK with their own self worth it would be devastating.
I do know that individuals can change this, so when your out socially talk freely about specific amounts of money you earn, or save, or spend. But be forewarned that it will make them uncomfortable. But if you can get a community built up where its considered the 'norm' then converting your workplace to use it (assuming they have enough of that community employed) can work.
Companies similarly worry about a hit to team cohesion that could result if team-members find out that some of them are paid much more than others.
It enables companies to pay employees as a whole much, much less.
Doesn't need much more explanation than that.
My theory is that American's believe the ability to assess your own salary and worth is largely part of the attributes of success and worth. Other countries believe more in the employer to define this.
Cool fact - In Norway, everyone's income is public domain: http://skattelister.aftenposten.no/skattelister/start.htm
I'm cringing at all the responses in here saying "this is why", as if it's some universal truth, when really it's just rationalizing the particular culture people have been steeped in. Why don't women walk around topless at the beach? Just culture. Some cultures see it as perfectly normal.
I wish people were more okay with it here in America. I make it a point to answer honestly if anyone broaches the subject, and to ask my close friends. Doing my part to change things. :)
(By the way, this should be obvious, but you should avoid naming numbers unless you absolutely have to. If a future employer asks what bonus you got, just say, regardless of what's true, "I received the highest bonus available for my role and seniority and I'm contractually disallowed to give specific numbers.")
This is also an area where it's hard to tell whether you'll need an upward or downward revision until you're in that situation. Upgrading makes it look like you were a strong performer whereas downgrading gives you a socially acceptable excuse for leaving a job or a better "trend". Of course, the smartest thing to do is not to give these numbers out ever.
I actually think LinkedIn is a bad idea for a lot of people, for the same reason, but pertaining to job titles and dates. Accidental consistency risk is enough of a danger (people who forget their exact job titles 12 years ago) to be cautious, and then consider the fact that, although people don't anticipate ever needing "creative career repair", shit happens and sometimes people do.
Finally, my attitude is just that it's none of anyone's business what I, personally, make. I'll gladly share my estimates of what various levels of engineer can earn on the market as it currently is, and my general sense of what engineers are worth, but strategically important information ought to be safeguarded, especially in this world.
It's pretty trivial to figure out what household income is within 10% if you know a person at all. Your privacy isn't something that employers give a hoot about.
As for salaries - it's a cultural thing, in the US/UK it is common to mention salaries in job offers (so you could compare easily), in other countries it isn't (or wasn't, like here in Austria, where new laws require mentioning minimum wages ...).
But all is not lost. It's hard to find a startup job where you won't be working closely with people from cultures where discussing your salary, rent etc. is perfectly normal.
That's how I was able to discover that as a woman I was making 75% of what my male colleagues were making. That's a Pandora's box type discovery, and I did stew on it for a while.
But I liked the company, and I didn't want to leave, so I saved that information for the end-of-year talks. They ended up bringing my salary level with the others', and then I was asked politely not to do that again.
It was quite uncomfortable for my boss - despite what you may think, your boss probably doesn't remember your exact salary - and I think my salary was an oversight (I was one of the earlier employees) rather than an intentional slight or because I'm a woman.
But still - what are the chances that could have happened if I hadn't asked my colleagues?
Don't ask, don't get.
Writer can't think of an explanation for secrecy about money and salaries.
> When I went to negotiate my first salaried job I had no idea how much to aim for. Was $30,000 a reasonable salary? $60,000? I realized then that everyone's aversion to talking about money had left me in the dark as to how the business world worked.
Writer inexplicably still can't think of a reason for secrecy about money and salary.
The reason is obvious -- keeping you in the dark pays off. The employer benefits from your ignorance. Other people in your approximate position, but who have the job you seek, benefit from your ignorance. Everyone benefits from your ignorance except you.
All I can say is, wait until you actually have some money and/or a salary. Then you'll understand.
> Why is everyone so hesitant to share their salaries and other financial information?
Because information has intrinsic value, and particular kinds of information have high intrinsic value. How many times have you read about a settlement between businesses in which the terms were sealed by a court order? Can you think of a reason why?
I am very grateful to everyone who showed me, through their transparency, that it is possible to make a living through self publishing books and software, so I've made a commitment to share my own numbers.
But I'm wondering what problems this transparency has caused as well.
I think the more we talk about it, the more we have to gain. It only hurts bad employers.
I guess the legality of such a clause will depend on where you live, but for people who have something like that in their employment contract, the risk may seem significant enough that it isn't worth violating it.
Just like you're disadvantaged when you fill out the "past salary" boxes on job apps.
Not feasible (or meaningful) if you work for IBM, maybe -- but for a smallish company that should work. If you can't do that math, you probably shouldn't be doing software engineering either...
Second, some companies like to get away with underpaying people. I'm not sure it's smart but they do. I know I worked with someone who did the same thing I did for 45% less.
1Q84 -- title's a nod to Orwellian dystopia; awesome mystery with a dash of sci-fi that takes place in a parallel universe sort of Tokyo; the English editon's 3 books in one so it's quite looong
Wind Up Bird Chronicle -- another 3-books-in-one psychological thriller, but the plotline's really just a device for telling the story of the Soviet-Japan border clashes during WWII and the atrocities committed by both sides; I loved the story but it's long and really weird, even for Murakami
Hardboiled Wonderland And The End Of The World -- really fun and imaginative book about a guy who can encrypt data by passing it through his subconsciousness, and ends up getting stuck there himself; I think this was the book that made Murakami famous in the US
1) Flowers for Algernon by Daniel Keyes. This book is an emotional roller coaster. After reading it, you will better understand what life is like for the mentally challenged.
2) Anna Karenina by Leo Tolstoy. You will get a glimpse into the life of Russian aristocracy in the 19th century. More importantly, you will learn about love and human relationships.
But yes , if you buy advertising on some websites , you may pay for impressions that never happened.
Feel free to ask more questions on the subject.
There are a bunch of vague reports that Obama's team had a similar failure of a big new computerized voter-tracking system on Election Day 2008, but they had also distributed the traditional paper "strike lists" to volunteers, so those were used as a fallback.
Never attribute to malice that which is adequately explained by stupidity.
1. The dot isn't required, your email will still work without it
2. I'd imagine people would be more appreciative if you actually pitched your idea. I know you responded below but more details in the original post is better. As well as more info about you i.e. what is the mystery school, what your background is before this, did anything else, where are you even located, etc...
3. I saw your response to another commentator and I don't agree that you need to build something to see if people will use it. Part of doing business is to go out, and get committed users who are interested in the idea. 130 pages is obsessive and it sounds like none of which included actual customers committed to the idea and feedback. 130 solid leads would be better than 130 pages at this point.
Three months of paperwork is great, but if the answer to the above two questions is no, said paperwork is sorta useless.
Just curious if this idea has been validated yet. Three months is quite a lot of time to spend on research - I'm curious if you have validated that people would use it.
I'd be interested in hearing about the research. The question I have is, why did you compile so much information? You mentioned 130 pages... that just seems like a lot for someone familiar with "Lean Startup" methodology.
Also, what is the idea? I don't need all the details, but I hope you can disclose the basic premise.
Also, in your research have you spoken directly to potential customers/users?
I'm a technical founder seeking co-founders as well.
You show a lot of drive and dedication. Best of luck!
I am not a technical person, but I am exactly at the same place you are right now;- looking for a tech co-founder.
I just wanted to say that this is a very well written post (just my opinion, I am a newbie too). I would use this as a template when I am looking for a technical co-founder.
I'd try good earplugs first, earplugs and your headphones next, earplugs and noise protection ear muffs next.
A simple $25 test is to get Laser Lite foamies and Leightning L3 earmufs. That's the best you can do without a helmet in actually blocking noise. If that's good enough you can optimize for comfort/size/style from there. If not, then try tricking yourself by pumping white noise through headphones on top of earplugs.
Personally, on planes I use http://www.howardleight.com/earplugs/laser-lite foam earplugs. 32 NRR. Any drug store or Amazon in bulk. You can still hear people, but even crying infants don't bother you much. And they get rid of engine noise. Most comfortable earplugs I've found. You need to learn how to put them in properly. Good enough NRR that when you open your mouth it gets noticeably louder.
When shooting I double up and wear MSA Sordin Supreme Pro-X upgraded with gel seals over earplugs. Get the neckband version. http://www.srstactical.com/communications/electronic-ambient... Sordins are 20 NRR by themselves. Probably 35NRR over earplugs.
For indoor handgun shooting I like Howard Leight Leightning L3. http://www.amazon.com/Howard-Leight-R-03318-Leightning-Shoot... 30NRR and extremely comfortable. Probably 37NRR over earplugs. They are big enough to cover a lot of area around your ears. When doubled-up you can't understand other people and can barely tell they are talking.
Get some earplugs (squishy silicone work quite well). Put them on under some earmuffs. I like the Pro Ears (just get the cheap passive ones). It basically buys you 29-30dB from the plugs and maybe the same up to 33dB from the muffs, which is pretty good (as much as 35dB?).
If you want or will tolerate music (or background noise):
In Ear Monitors, ideally with custom made earmolds. Try a cheap pair first just to see if you're comfortable with the feeling of having earphones crammed in your ear canal, but if you like those, I'd strongly suggest getting custom earmolds made at an audiologist (maybe $200).
I have both Etymotics ER-4s and Logitech Ultimate Ears 6vi.
I wore them (underneath my electronic shooters muffs, sometimes, other times bare) on ranges with 14.5mm machine guns firing, as well as on helicopters, and they are awesome. Essentially 29-30dB earplugs and audiophile-grade headphones. As a plus, they're the size of a set of earbuds.
These are what professional musicians wear on stage.
The absolute best are the custom Ultimate Ears (well, there are 2-3 other great brands) -- they go up to about $1500. You can get what I have for $100-300, and those are also great.
Also, uh, Ambien. For her or yourself.
In my opinion sound isolation headphones blow away noise cancelling headphones for air travel. As long as you're comfortable with the look.
Some other suggested the etymotics, but I can't stand in ear phones, or ones that rest on your pinna. I find them so uncomfortable. The Ex29s are circumaural so are very comfortable for long sessions.
If someone really takes on this problem, my anecdotal experience is one of having encountered a significant number of people who would buy in. People looking for an Apple-like experience: High quality manufacturing and performance combined with a simple choice or set of choices. This includes ergonomics; for example, in addition to not providing complete attenuation, tightly sealing over-ear muffs can become extremely uncomfortable, tiring, and physically distracting during extended wear.
Our maybe a pill, like some analgesic, freezing your auditory nerves for a while.
I have noticed that loud speaking is much less disturbing if you don't understand the language, maybe a drug messing your language brain could help, but if the purpose is to think about something else it will not help...
I bet the best fix is to tell this women you have misophonia, and pray her to tone down a bit.
or, with an iPhone compatible microphone:
You can stand in front of a V6 engine at full throttle and will barely hear it.
Those are the ones I have:
If the objective is a standalone device for noise isolation, those are the closest you're likely to get.
Slightly better would be the earbuds you see with scalloped inserts (the kind that look like this: http://gearmedia.ign.com/gear/image/article/771/771337/gdc-2...) -- they have more layers of insulation when inserted, and have the added benefit of being able to be augmented by speaker-borne audio.
With the Bose noise cancelling earphones, it's actually considered a feature that they don't block out conversational frequencies.
Bose does make some commercial-grade noise canceling headphones. They're like 1k but I'd be willing to bet they would work too