I did the same. I founded a VPN provider in my free time. It is still running, but I have at times been close to shutting it down.
Most of my code has been open the whole time and is on github. Some internal tools and the website are not on github though. I went with AGPL for license. It'll make my day if someone forks my code and founds their own provider.
I operate out of Iceland and most of my clients are Icelandic. The biggest use case for my service was ISPs in Iceland charging extra for international bandwidth. By having my servers in Icelandic datacenters, I was able to provide my customers with significantly lower prices for bandwidth, thereby lowering the cost of internet for a lot of people. Considering the huge time investment that has gone into this side project, I have not made much money from it. But knowing that I helped my internet usage more affordable is something that has made this project meaningful for me.
Since I started, lots of things have changed. Some ISPs are now offering unmetered connections (this was unheard of before). Others have lowered their prices. I have heard people attributing part of these changes to me and my company.
I have not experienced DDoS attacks like you, but I have been the subject of meetings at some regulatory boards in Iceland, as well as at the monopoly behind the submarine cables connecting Iceland to the world (the source of this dual-pricing schemes). One hosting provider was forced to change their core routing shortly after I starting hosting with them, to make me unable to host there. Other providers have come under preassure from this monopoly to kick me out. Like you said, you feel like your service was real -- someone with a vested interest against it was watching me.
Some time in the near future I will shut down the service. It's just time to move on to other projects and time to recognize that it's fulfilled it's usefulness. I know I will walk away from this project with a great sense of accomplishment, I am proud and happy with the work I did.
I first got an idea for this after publishing my OpenVPN docker image  which received more attention then I ever imagined. The BackRoad service runs all the VPNs with the exact docker image in the public github repo + CoreOS and all that jazz to make it scale.
I come from a hardware background where starting something is completely different then a web service. I think it's interesting with only minimal risk as you've pointed out.
Thanks for sharing!
-Which VPN server software did you use?-Did build your own custom client wrapper, or did you have people download something like OpenVPN and enter the configuration info themselves
-How many customers did u end up getting?-Was it hard to acquire customers?-Were people more price sensitive or feature sensitive?
I'm all for more great and easy-to-use VPN tools! :)
I guess that you must really be craving attention or perhaps it was a part of your marketing pitch, but try and not exaggerate things beyond ridiculous. Internet in Russia is a far cry from being "very limited". I travel there every few months to see family and I'm yet to hit any limitations or blacklists.
What I would recommend instead, is save up a bit of money and move to another country (South America, Southeast Asia, even Eastern/Western Europe if you can swing it). There you will not fail background checks, and in many countries you can easily get a job teaching English (with or without a small amount of training) which will be more than enough to pay your bills. Your quality of life will be far higher than living with your parents.
Start a consultancy doing the skilled work you want while you pay your rent by teaching English. Work on your social skills, and probably the deep underlying reasons those skills are lacking (by the way, this will help building the consultant work over time). Take some psychedelics, get outside your comfort zone with people and activities, enmesh yourself in a new culture, learn a new language. This will all take time, and I'd encourage you to keep moving between cities or countries a bit until you find a situation that feels right and you don't want to leave.
You don't like who you are now, so become the new person you want to be. It will be a lot easier to do that in another country. Even if the felony would prevent you from getting a permanent visa immediately, you'll be able to indefinitely do visa runs in the vast majority of developing countries with little hassle.
Work hard to get a new job, even if it's a crappy one. This will be the key to help you turn your life around. I know it did for me. I struggled during my early late 20s too, and when I turned 30 it felt overwhelming... like what have I been doing with my life? But when I put my head down and started to work hard.
Career became my main focus in my 30s and while I am much older now, I can say without doubt, everything got better. I was able to not worry about money, date more, make more friends, indulge in personal interests, etc.
Use this time living at home to save, take any job related to your interest. Keep looking for better opportunities. Save more money. Get that job. Get that girl. Get your life turned around mentally and emotionally. Don't dwell on the past. Good luck!
A lot of the issues you have could be the result of a distorted life perspective. Superficial advice like "lift weights" are not helpful. You need to change your thinking patterns to have results that last.
I've learned that just being like "yo I can't pass a background check in case you were wondering" only opens up arms and minds. Though, to a felony sex offense... well, it couldn't have been that bad since you did 3 years probation. I got 5.
Reach out to some bigger recruiting agencies, and make sure to prepare yourself for an explanation. From what I've experienced, they'll do the background check, and then ship you off to companies where you won't have to pass theirs.
A question I have for you is this: How has finding a place to live gone for you?
Edit: just remembered that I'm off probation in late August. Yay.
The felony: in some cases an attorney can get these reduced to a misdemeanor if you stay out of trouble several years after your probation is over. You might look into this.
The career: there probably aren't any shortcuts. Like a lot of other things, it's a numbers game. Keep sending out resumes and applications, the more the better. Try not to get discouraged (or, at least, don't let that stop you from putting out another resume and application). Do some work in the field. Do anything you can to get your foot in the door somewhere, to keep moving towards your goal. Internship maybe? Somewhere out there is someone who will give you an opportunity. You have to find them.
Keep working on and improving yourself. Get out and socialize if possible. (Meetup is good for this in a lot of areas.) Don't wallow too much in self-pity; learn to be happy with yourself and others will be happy with you too.
Your 20s is disappointing because you screwed up in a way that's going to affect you for a long time. So don't screw up; make your 30s about working towards your goals and recovering from your past decisions. Be stable and reliable and responsible -- become an adult.
I ended up working a string of minimum wage jobs before finally finding a factory job that was hard, but paid a little more ($13/hour). Since I really wanted to be a professional drummer and tour with a band, I figured that I needed to learn a skill that I could do on the road. I decided to start studying web development and graphic design. I worked a bunch of overtime, bought a used macbook, and started spending all my nights and weekends studying (I have a friend who calls this the Overlap Technique; google it). After a couple years, I had learned enough to get an (unpaid) internship at a small web design agency. That eventually gave me the confidence to start taking on freelance clients when the opportunities came.
The hardest part was learning to like myself again. By the time I was 20, I was overweight at 260 pounds (I'm 5'll). I started making small changes to my diet (stopped drinking soda, started eating healthier foods), and I started walking, exercising, riding my bike around town, etc. I lost 80 pounds over the course of three years, and I felt and looked really good.
I was also fortunate enough to find a group of cognitive therapists who were really smart and really kind who helped me understand the thought patterns that were making me fuck up my own life.
I had two major breakthroughs; the first was after taking shrooms (not a recommendation, mind you) I realized that I could make my life be whatever I wanted it to be. I had control over my decisions, and they would shape my life.
The second was that I had to stop giving a fuck about what the people who didn't know me had to say about the poor choices I made in the past. I understand why I made those shitty choices, and I won't be making them again. If someone wants to be a dick or refuse to work with me because of a bad choice I made in the past, they aren't someone I want in my life anyways.
I turn 30 in two months. I have a solid source of income from multiple clients who I have good relationships with (they've never asked for a background check), a nice girlfriend, and plenty of friends who know about my past and still respect me for the person I am today. They can't even comprehend the level of shithead I was back then because today I am nothing but kind, respectful, encouraging and helpful to everyone I meet.
I hope this helps.
I think the psychological baggage of living with your parents, not having a girlfriend and having a degenerative neurological disorder is far greater than the criminal record. There are ways to reduce the implications of the sex offense on your life, as others suggested. But the other things are what will hold you back.
Consider adopting a meditation practice and practice being nice to yourself. Calling yourself "broken goods" isn't helping matters. The way you think of yourself is the way you carry yourself and how other people see you. Seek examples of happy, accomplished people with missing limbs or serious illnesses.
I found that with a decent salary, meaningful remote job, traveling across some of the most beautiful places in the world and eating amazing food, I came to realize I deeply miss my friends, lack having a local community, and a purpose and meaning in what I was doing.
My best advice if for you to seek ways to bring value to other people's lives through what you do. It doesn't have to be selfless, it can be as simple as writing a blog and sharing your journey. It may take a little while to figure out what brings you happiness, but whatever you do, even if you get a freelance/remote job, don't stay inside and work for days without meeting people. Coworking spaces and cafes are a much better alternative in your situation.
Go and get another job as a statistician - by this I do not mean applying for them. Work out where you want to work (ish), find some excuse to get to know people there and just talk about coming to work for them. Is there an annual "stats in the advertising industry" conference? Go there, pay attention, talk to people about stats. Pretty quickly, if you know your shit, doors will start to open.
I got a job offer off a usenet post once.
When it does get to the point where you're physically in their building and talking about whether or not you could come to work for them, fess up. "You should know I've made some mistakes in my past and ... my legal record shows this ... I want you to know before you find out".
Voila. Do the full Trainspotting thing - washing machine, big fucking TV etc. Then meet some women and just be nice. Problem solved, I guarantee it.
There's (generally) no background checks required for starting or running a business.
You have listed the constraints that currently apply to your life. Think about what sort of life you can create within those constraints, or how you can get around them.
Part of the pursuit of an "interesting" lifestyle hopefully will get you into networking situations where you might find friends and maybe more romantic interests that share your pursuits.
Stop waiting to start somewhere, and just start.
The single best suggestion I have for you is to surrender your life to Jesus. God did miraculous thing for me since I decided to let Jesus live in me. I was in search for meaning and found it in Him.
And you don't have to believe me; please ask some people around you who believe. Maybe in your family. They'll probably tell you how God changed their life for the better.
I know you said you're more interested in having a good job/salary and it's OK to seek that, but please also consider your after-death. Jesus said: "For what will it profit a man if he gains the whole world, and loses his own soul?"
God bless you. I'll pray for you my friend.
When you stop seeing yourself as broken goods it'll shine through. Besides, no one knows you until they want to know you. When you project your brokenness that's how they will see you too.
workout, try to stay in shape as much as you can.
2. Start trying to meet more people and make more connections Friends, acquaintances, professional colleagues. Go to where people doing the type of statistics/marketing you're doing hang out, and get to know them. In-person is better than online, but if you're not near a major metropolitan area, online would be okay too.
You could, for instance, find some discussion forum devoted to marketing/statistics, and learn, post there, follow up, etc.
It doesn't have to be purely professional related, but if there's overlap between the work you want to do and the type of people you're meeting, you'll have more job offers. There's a number of studies showing that the vast majority of hires made aren't from applying blindly by sending in resumes, but based on recommendations and personal relationships.
So -- get to know more people. It'll probably also help with your self-esteem. I'd also recommend never calling yourself "broken goods" or similar again: the world's got enough antagonism in it without you getting on your own case.
But yeah, your main goal is get employed? Start meeting people, getting to know them, and showing your competence in the areas you'd like to be employed.
Your other options are mainly going to involve under the table jobs or freelancing, probably your only meaningful option if you want to continue in your previous line of work. Why not hang out your shingle as a contractor? Since you're not working anyway, it can't hurt! If you have contacts from previous jobs, get in touch with them and offer your services -- as a services corporation, not as an employee. You might have more success as a corporation than as a human.
A friend of mine had an addiction and started with this and it worked out so well for him.
Next you need to hit the gym, and start small and try 3 days a week.
Second make some goals about things you want to get done before you reach next year.
Next do deep introspection, think about your self in the third person, and ask your self what you hate about yourself.
Go write it down and spend a everyday on one of those things and chip away at it by breaking it down into smaller tasks.
Lastly Smile people love other people who smile, it makes them more approachable.
Reddit says, 30 is the best of your life if you are not married or tied down to a relationship.
Need support feel free to hit me up on twitter? @0xFA11DEAD
Story time: 2 years ago I started to learn frontend web development from various online courses. I had zero technical background and no intention to make money. Within few months I learned enough to create my first WordPress theme. It was terrible but it worked . I made few more themes and never did anything with them. I made like 6 themes and just deleted theme few months down the road. Then I decided to submit one theme on WordPress.org just to see if it gets approved. Themes goes through review and someone would evaluate my code and that's what I was after. Long story short my themes now have been downloaded over 1,000,000 times and I have turned it into 6 figure a year business.
While I haven't sold a single theme yet, apparently you can recommend hosting and premium plugins that goes along with your themes and make a decent income.
For those interested you can visit site at: https://colorlib.com/
If you're interested, I recommend listening to his interviews on the ChangeLog Podcast (https://changelog.com/159/, https://changelog.com/130/, https://changelog.com/92/) where he talks about how he monetised those products.
I'm pretty sure that succeeding in this is not going to be a matter of how many "stars" your project has, but rather a function of the dollar value of the problem your software solves and how well you market the paid product. You should start that marketing now by providing a link to your project :).
Hundreds of tutorials and thousands of posts and mentions later, GitHub eventually contacted me and politely asked me to take down the exchange rates repository, because they were being hammered by people requesting the data - only at this point did it occur to me that I'd created something of genuine value, and (6 months of fretting and tail-chasing later) I opened up a paid option.
For me the key thing was: I never intended to create a business. It was (and is) a labour of love. We've since grown to be the industry-leader for our area - "good enough data" for the startup and SME market - and count Etsy, KickStarter, WordPress and Lonely Planet among our clients.
Although it's no longer truly open source, 98% of our users are still on the Free plan, which will very soon be expanding to include all features (so, no more limiting by price tiers) - this is how I still feel so passionate about it.
I can't wait to publish the next steps in our journey - where we're opening everything up to the community and marketplace. I don't like where the industry is heading (competitive, closed, secretive) and we've chosen to move towards transparency and sharing.
I like businesses built on a core of open source community, because they're in service to the people who are actually building the products, rather than those in the traditional 'upper levels'. This means there's really no "sales process" (which I'm massively allergic to) - apart from the occasional grilling from the accounting department, who may find it hard to trust a business based on open source principles.
Seriously though, the fact that you're asking about GitHub stars is... telling. There's plenty of popular repo's on GitHub that I'd refuse to pay any money to, but more to the point, GitHub is a terrible customer experience because it's not for selling software to people, thus the only thing 'GH stars' tells us is... the number of people that have starred a particular repo.
For a purely open-source project, look at OpenSSL. It's probably in production in a significant amount of the entire internet. But until Heartbleed came along and it came to light that the OpenSSL project was severely underfunded, it was limping along with little sponsorship.
Red Hat is probably the most famous open source business, but unfortunately, if you look at their practices, they're abiding by the letter of the GPL, but not entirely the spirit, which they've decided is necessary from a business perspective, so if you're looking to make a lifestyle business based on your open-source project, the question to you is: how comfortable would you be with a lifestyle business based on an entirely proprietary project?
Is this a pipe dream? Chances are, yeah. But do dreams come true? Sometimes :)
* Paid support: you now have an incentive against improving the documentation. Conflict of interest.
* Selling binary builds: your software can no longer be easily recommended and shared by others.
* "Premium features": I'd rather call this 'crippleware'. You're intentionally crippling the 'community version' to give people an incentive to pay you money. That's certainly not in the spirit of open-source.
Frankly, I don't feel software is a thing that should be sold at all. You're always going to be intentionally (and artificially) restricting something to make that business model work - after all, software is infinitely reproducible at effectively zero cost.
Instead, if you absolutely must make a business out of it, offer something like a hosted service (that people can easily replicate themselves, in the spirit of open-source). That way you add something to be sold, rather than taking something from the existing project and asking money for it.
The better option is to accept donations, and put some serious effort into getting those going. I don't really understand why people will spend weeks drawing up a business plan, but for donations they just slap a 'donate' link in the footer of the page without thinking, and then complain after a few months that they're barely getting any donations. Accepting donations requires the same amount of thought to make it work.
EDIT: No bulletpoint lists on HN? :|
Here's what I would suggest. Reach out to a few people from these organizations and ask them for their general views on your project and what their major pain points are. I'm sure they will be more than happy to talk to you about it if they're indeed already deriving great value from it. Once you have established a good rapport (i.e. warming up the lead), set-up a call with them to pitch your vision for the paid product. A call is crucial because email and text can only communicate so much - you can get a far better idea of their domain and problems through a quick 45 min call. Scheduling this should not be a major problem once you have established a good email channel previously.
If you can get about 8-10 people interested in exploring your paid offering you have something that's promising. After that you can think about scaling the business with self-service etc.
Every company that emails you asking you for help is a sales lead. "I'm happy to implement/configure this for you. I charge $X per hour, and what you're asking for is about Y hours of labor." To the client, X*Y is often cheaper than the opportunity cost of pulling an engineer away from other work. Also, don't be afraid to make X >> $100 if nobody else offers the same expertise.
You can do as much of this as you want, without changing anything about how the software is licensed or packaged.
Would you rather make $300k a year writing and selling proprietary software or fail/make $20k a year providing value-added services for an open-source project? This isn't a tough choice for me, but for some people the ideal of open source trumps all.
It's much easier to write software that fits a simple business model, than to figure out how to shoehorn a business model onto an open source project. You can tell which route is the pragmatic one: start from scratch, optimize for easy monetization.
That said, don't let any of this discourage you. It's absolutely possible to create a cool lifestyle business based on an open source project (or anything really). The only way to know if you can do this is to seriously commit to it. If you don't have to support a family it's probably a risk you can take.
2) "some guy" from one of the podcasts I can't think of at the moment who forks Ruby and keeps a stable, supported version for his corporate clients, while dealing with patches & upgrades on his own to his fork
In both of these cases, you can see that is isn't actually "how many users", but "how many corporate users who need a service that keeps software X completely stable and managed"
So I think from what you've said that it would be a good thing to look into. You may want to contact the guys from http://www.tropicalmba.com/ for a few pointers - this is right up their ally and they are very willing to discuss
I would start with a services plan and a beautiful website. If you are not a designer, do hire one. Good design and quality can go a very long way towards achieving your dream.
If your project is an app, you can also go the SAAS (softare-as-a-service) way. But beware, building a multi-tenant platform, and working on user onboarding, marketing your site can be 2x to 3x of your original project your project.
The good thing is that once you are there, 1/2 years is a reasonable time, this will only grow.
Another quantitative indicator you can use is number of downloads on relevant package manager (npm, PyPi etc.). These indicators only tell you how big your audience is and not whether your project could provide income. However, having big audience increase chances of success - you have a good position here.
Check out MinoHubs (https://www.minohubs.com). We provide tools that will help you get started with monetizing your project in several ways very quickly. Let us know if you have any questions or if you're missing anything.
If you make it easy for people to give you money and you have a useful product then there usually will be a small percentage of users who will pay. But I'm a firm believer that to make money you have to put effort into sales.
So I am very sceptical about monetization of community-driven momentum (the moment you close the code it begins to stagnate and die). Unless you are leader in your niche the chances for earning living from a project are close to zero.
Wordpress or other themes is a different kind of offer.
I think Nathan's book describes an excellent outline for success in this regard. Basically you can look into "tiers". You give away "free" resources. Blog posts and the liberally licensed open source software itself. You can also paid resources. A book, perhaps screencasts that accompany the book for a premium price. Workshops and onsite training provide another tier. At the very top is consulting at ultra-premium rates.
This is oversimplified, but this is the idea. The "free" stuff is critical, and builds the basis and "proof" for the paid offerings.
Others have discussed busies models, so it should be a simple calculation of how much you can charge for a model vs how much it will cost you to run your business and if you can live with the reminder after taxes etc... then I would say do it.
 - https://github.com/joeblau/gitignore.io
There are excellent comments in this thread btw. I've bookmarked it.
100,000 star. If you are starred by your average to not-so-average (high or low) developer. There is no clear monentization plan. But given the popularity, ads and affiliates might bring you $1 per star (assuming a star is 40-50 visits/year).
Think about it. You have a bridge between Queens and Manhattan. I'm sure the US, NYC and people are willing to finance, pay you, or buy you. For what-ever big price (might be unreasonable too, to the cost of creation) you ask.
But if you have a bridge between Antarctica and the French Southern Antarctic lands (just randomly picked), it'll be certainly an amazing and well-known artefact but I'm not sure how you are going to finance it (especially that Tourism is not huge there).
a) 100k / year is not 'reasonable', it's huge in microisv terms. The modal revenue for independent software vendors is $0 (stats from payment processors). To get there in 2 years is even less common.
b) The number of 'stars' has correlation r=0 with ability to monetize. I'd even speculate - the more stars, the more ingrained in people's heads it is 'this is open source, ergo free', the harder it will be to make money. If you're selling support for something only slightly popular, customers will have no other options - but on support for Wordpress, you have to compete with other devs, with 2$/hour rentacoder people, with Amazon selling 'teach yourself Wordpress in 60 minutes' books etc.
c) What incentive do companies have to pay for it? You have to be able to articulate it clearly before going down this path. Your wording makes me think you are thinking 'this is my secret sauce, I can't give it away', which is (frankly) very naive. If your idea is even a little bit good, you'll have to stuff it down people's throats to accept it. I don't know of any business that makes money OS software (on the software itself, not the consultancy around it) without having a dual licensing model - GPL or commercial. And if that was really a cash cow, Trolltech wouldn't have been sold a dozen times (or so) over the last 10 years...
To judge whether your product has commercial potential, you need to
1) Describe your customers. In detail. Not just 'anyone using a database', but 'medium scale accounting businesses with on-premises case database' (idiotic example, of course). You need to do this in such a way that you can derive a strategy from it on how to find them. E.g., accountants meet at industry events, where you could book a booth.
2) Identify a sample of, say, 100 of them, using the methods from step 1.
3) Start calling them. Preferably after you've taken a sales class (just 2 days will give you life changing insights, I promise). Not emailing, actually talking to people. For the 100 from step 2, identify how many would buy your product.
4) Get sales promises, 10 or 15 or so. People who you can excite so much about your product that they promise (informally) 'yes, I'll buy this if you offer it within 6 months' or whatever.
5) If you can't even do this, you have no (OK, 'barely any') hope of succeeding.
The main skill you need is marketing to succeed at an endeavor like this. The quality of your software, or its popularity amongst the crowd that uses Github, is of secondary importance at best. That's not to say that you can succeed with selling people crap product, snakeoil style, just that your life as a software vendor is 10 or 20% of software development, at best (or worst, depending on your perspective...)
I started making money in 2011 with a GUI for an open source command line tool. The open source software was available completely for free, but compiling it was a hassle, using it was annoying because of a few serious bugs, and you had to use it from the command line.
I made money by making an existing, free tool available to people who didn't want to use the command line or compile their own software. I charged a modest fee (initially just $5), and people gladly bought my app to solve their problem. Nobody cared about the fact that it was open source and they could have solved their problem for free; they just considered my app a fair deal.
(I still sell this app, MDB Viewer for Mac, but I've since completely rewritten the open source library it depended on)
My company is based on Open Source software (Webmin, Virtualmin, Cloudmin, and Usermin), and it sounds sort of similar to your situation. When we started the company based on this stuff we had several major companies in our target market (and we chose our target market, and chose to focus on Virtualmin rather than other features of Webmin, because that market already knew us and used our software in visible ways) using at least one of our projects, almost a million downloads a year, and my co-founder and I had both been making a decent living doing contract work based on it and writing about it.
Today, Webmin has about 1 million installations worldwide (and has grown to ~3.5 million downloads per year). We make enough money from our small proprietary extensions to Virtualmin and Cloudmin to support three modest salaries. It is not $100k/year for any of the three people working on it, though it's not an outrageous dream to think we could get there..we've had much better years than we're having this year or last year, however, so revenue is not necessarily growing like gangbusters, despite our userbase roughly tripling in the time the company has existed and still growing at a comfortable clip annually. Ours is sort of an open core model, though the core is very large (~500kloc) and the proprietary bits are very small (~20kloc), which may be part of our revenue problem.
I think there are some things you're probably underestimating (not to say it should discourage you, I'm just trying to open your eyes to some challenges you will face that you might not expect):
When you sell Open Source software, support is your biggest value add, even if you don't want to be a support company. Support costs a lot of time and money to do well. Time and money has to be balanced between making things better and supporting existing users on the current version (true of proprietary as well, but proprietary vendors don't have a million people using the free version and expecting help). Growing the free user base (which can be a side effect of having people working full-time on it) can paradoxically lead to less time and money for making the software better. We fight this battle all the time. To make our current customers and OSS users exceedingly happy with our level of support is to severely limit our ability to deliver next generation solutions. We run on such a shoe-string, and compete with such huge players, that it's always a struggle to deliver both (and we fail plenty).
So, plan to hire someone to help you support the software, eventually. If we were comfortable leaving our forums to "the community" and not bothering to have an official company voice present every day helping answer the hard questions, we could increase our own salaries by a lot (we pay our support guy more than we pay ourselves), but I don't know that we'd continue to see the growth we've seen in our user base, which we also value. We make things because we want them to be used, not just because we want to make money.
Get used to having demands thrown at you every day. The level of documentation and completeness and rapidity of development expected of a product is vastly different than that of an Open Source project, or at least the way you have to respond to it is different...even for users of the Open Source versions. We have over 1,000 printed pages worth of documentation, plus a couple hundred pages of online help, and still get complaints about our documentation regularly. And, we have more "features" than any other product in our space, including the two big proprietary competitors, and yet still get feature requests all the time (and it's harder to say no than to just implement it, which can hurt usability). A million users generates a lot of feedback. It's a very high volume of demands to answer to. Ignoring them pisses people off, saying no pisses people off, and saying yes often risks making the product worse or more complex for the average user, hurting long-term growth. Even saying, "Not right now" pisses people off. You're going to piss a lot of people off, even if you're just trying to make the best software you can and make a decent living.
I think what I'm trying to say is, think about it for a while before committing to your plans. If you currently have steady income, hang on to it while you sort out a few details.
Try to firm up what your users would pay for your value add. Try to figure out how many of your users would pay for your value add. The only sure way to do this is to actually have users pay you something for your value add.
Try to figure out how you will automate support (hint: You can't, because automated support almost always sucks; even Google has awful automated support, and they're good at almost everything.) At least figure out how you will streamline it and offload it; have an active forum already? If not, get one. Have a community of people talking about your software already? Get one. If Open Source based business were a Pokemon, community would be its special ability. So, you should start cultivating that now, even before money is coming in.
Cachet (https://github.com/cachethq/cachet) has 2.6k stars but I know that the amount of installs is actually far higher.
Revenue is number of people willing to pay you time the amount they're willing to part with. Neither of those can be inferred from number of stars on a GitHub page (it probably has the most correlation with the number of people willing to pay, but there's going to be a scaling factor there that will vary dramatically based on the nature of the project).
How do you envision your open source lifestyle business once it is up and running? (do you want to be paid to develop software or are you hoping to make a business that "runs itself"?)
There's your answer
You need to provide a service connected to your project, this is regardless of how many people use your project.
Was it worth it open sourcing your product?
Did you get lot more leads and exposure?
I'm afraid of open sourcing because I'm not sure if it will do anything for me, and that I'm giving away years of work away for free.
it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects.
the idea is, you need to know as much as possible right away. so you run these scripts and you get a map which immediately identifies which files are most significant. if it's edited frequently, it was edited yesterday, it was edited on the day the project began, and it's a much bigger file than any other, that's obviously the file to look at first.
we tend to view files in a list, but in reality, some files are very central, some files are out on the periphery and only interact with a few other files. you could actually draw that map, by analyzing "require" and "import" statements, but I didn't go that far with this. those vary tremendously on a language-by-language basis and would require much cleverer code. this is just a good way to hit the ground running with a basic understanding which you will very probably revise, re-evaluate, or throw away completely once you have more context.
but to answer your actual question, you do some analysis like this every time you go into an unfamiliar code base. you also need to get an idea of the basic paradigms involved, the coding style, etc. -- stuff which would be much harder to capture in a format as simple as bash scripts.
one of the best places to start is of course writing tests. Michael Feather wrote a great book about this called "Working Effectively with Legacy Code." brudgers's comment on this is good too but I have some small disagreements with it.
My comment from that thread:
I do the deep-dive.
I start with a relatively high level interface point, such as an important function in a public API. Such functions and methods tend to accomplish easily understandable things. And by "important" I mean something that is fundamental to what the system accomplishes.
Then you dive.
Your goal is to have a decent understanding of how this fundamental thing is accomplished. You start at the public facing function, then find the actual implementation of that function, and start reading code. If things make sense, you keep going. If you can't make sense of it, then you will probably need to start diving into related APIs and - most importantly - data structures.
This process will tend to have a point where you have dozens of files open, which have non-trivial relationships with each other, and they are a variety of interfaces and data structures. That's okay. You're just trying to get a feel for all of it; you're not necessarily going for total, complete understanding.
What you're going for is that Aha! moment where you can feel confident in saying, "Oh, that's how it's done." This will tend to happen once you find those fundamental data structures, and have finally pieced together some understanding of how they all fit together. Once you've had the Aha! moment, you can start to trace the results back out, to make sure that is how the thing is accomplished, or what is returned. I do this with all large codebases I encounter that I want to understand. It's quite fun to do this with the Linux source code.
My philosophy is that "It's all just code", which means that with enough patience, it's all understandable. Sometimes a good strategy is to just start diving into it.
After that, if I don't have a particular bug I'm looking to fix or feature to add, I just go spelunking. I pick out some interesting feature and study it. I use pencil and paper to make copious notes. If there's a UI, I may start tracing through what happens when I click on things. I do this, again with pencil and paper first. This helps me use my mind to reason about what the code is doing instead of relying on the computer to tell me.If I'm working on a bug, I'll first try and recreate the bug. Again, taking copious notes in pencil and paper documenting what I've tried. Once I've found how to recreate it, I clean up my notes into legible recreate steps and make sure I can recreate it using those steps. These steps are later included in the bug tracker. Next I start tracing through the code taking copious notes, etc, etc. yada yada. You get the picture.
Set a breakpoint, burn through the code. Chrome has some really nice features - you can tell it to skip over files (like jQuery) you can open the console and poke around, set variables to see what happens.
Stepping though the code line by line for a few hours will soon show you the basics.
I use a large format (8x11 inch) notebook and start going through the abstractions file by file, filling up pages with summaries of things. I'll often copy out the major classes with a summary of their methods, and arrows to reflect class relationships. If there's a database involved, understanding what's being stored is usually pretty crucial, so I'll copy out the record definitions and make notes about fields. Call graphs and event diagrams go here, too.
After identifying the important stuff, I read code, and make notes about what the core functions and methods are doing. Here, a very fast global search is your friend, and "where is this declared?" and "who calls this?" are best answered in seconds. A source-base-wide grep works okay, but tools like Visual Assist's global search work better; I want answers fast.
Why use pen and paper? I find that this manual process helps my memory, and I can rapidly flip around in summaries that I've written in my own hand and fill in my understanding quite quickly. Usually, after a week or so I never refer to the notes again, but the initial phase of boosting my short term memory with paper, global searches and "getting my hands to know the code" works pretty well.
Also, I try to get the code running and fix a bug (or add a small feature) and check the change in, day one. I get anxious if I've been in a new code base for more than a few days without doing this.
Two things I do to familiarize with a code base is to look at how the data is stored. Particularly if its using a database with well named tables I can get some rough ideas of how the system works. Then from there I look at other data objects. Data is easier to understand than behavior.
The other is watching the initialization process of the application with a debugger or logger. Along those lines if your lucky (my opinion) and the application uses dependency injection of some sort you can look to see how the components are wired together. Generally there is an underlying framework to how code pieces work together and that generally reveals itself in the initialization process if its not self evident.
I just cannot believe people praising 'Unit Test'-ing. Fellow programmers, how exactly do you unit test a method / function which draws something on the canvas for example? You assert that it doesn't break the code?!
I see some really talented people out there who write unit test as proof that their code works without issues, that it's awesome and it cooks eggs and bacon etc. They write such laughable tests you cannot even tell if they are joking or not. They test if the properties / attributes they are using in methods are set or not at various points in the setup routine. Or if some function is being called after an event is being triggered.
My point is this: unit testing can only cover such tiny, tiny scenarios and mostly logic stuff that it is almost useless in understanding what is going on in the big picture. Take for example a backbone application like the Media Manager in WordPress. Please tell me how somebody can even begin to unit test something like that.
Unit testing is a joke. And sometimes a massive time consuming joke with a fraction of a benefit considering the obvious limitation(s).
As such my first steps are:
1. tidy/beautify all the code in accordance with a common standard
2. read though all of it, while making the code more clear (split up if/elsif/else christmas trees, make functions smaller, replace for loops with list processing)
While doing that i add todo comments, which usually come with questions like "what the fuck is this?" and make myself tickets with future tasks to do to clean up the codebase.
By the end of it i've looked at everything once, got a whole bunch of stuff to do, and have at least a rough understanding of what it does.
I always start by gauging how much source code there is and how it's structured. The *nix utility "tree" and the source code line counter "cloc" are usually the first 2 things I run on a codebase. This tells me what languages the applications uses, how much of each, how well commented it is and where those files are.
The next thing I usually do is find the entry point of the program. In my case this is usually an executable that calls into the core of the library and sets up the initial application state and starts the core loop and routine that does the guts of the work.
Once I have found said core routine I try to get a grasp for how the state machine of the program looks like. If it's a complicated program this step takes quite a while but is very important for gaining an intuitive understanding of how to either add new features or fix bugs. I like to use my pen and paper to help me explore this part as I often have to back track over source files and re-evaluate what portions mean.
Once I have what I think is the state machine worked out I like to understand how the program takes input or is configured. In the case of a daemon that often means understanding how configuration files are loaded and how the configuration is represented in memory. Important to cover here is how default values are handled etc. I actually prioritise this over exploring the core loops ancillary functions (the bits that do the "real" work) as I find it hard to progress to that stage without understanding how the initial state is setup.
Which brings us to said "real" work. Hanging off of the core loop will be all the functions/modules are called to do the various parts of the programs function. By this time you should already know what these do even if you don't know how they work. Because you already have a good high level understanding at this point you can pick and choose which modules you need to cover and when to cover them.
1. The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another.2. The Core: Try to figure out how the code works with regards to these main concepts. Box and arrow diagrams on paper work really well.3. Key Use Cases: I would suggest tracing atleast one key use case for your app.
This allows you to go down any code rabbit hole, figure stuff out, then get back to where you were. If you can't do those things it will take much longer to understand how things are interconnected.
Some others have mentioned recency/touchTime as another signal. For large complex codebases, that may or may not always work.
1. Be sure what you can compile and run the program
2. Have good tools to navigate around the code (I use git grep mostly)
3. Most of the app contain some user or other service interaction - try to get some easy bit (like request for capabilities or some simple operation) and follow this until the end. You don't need a debugger for it - grep/git grep is enough, these simple tools will force you to understand codebase deeply.
4. Sometimes writing UML diagrams works -
- Draw the diagrams (class diagrams, sequence diagrams) of the current state of things
- Draw the diagrams with a proposal of how you would like to change
5. If it is possible, use a debugger, start with the main() function.
For the ajax data source thing, I would try to modify or extend the existing data source code to add the behavior you are looking for. As you mess around with it trying to figure out what you need to change, you will encounter the areas of the code that you need to understand.
With this sort of strategy you can avoid having to fully understand all the code while still being able to modify it. You might end up implementing stuff in a way which is not the best, but you will probably be able to implement it faster. It's the classic technical debt dilemma: understanding the complete codebase will allow you to design features that fit in better and are easier to maintain and enhance, but it will take a lot longer than just hacking something together that works.
I keep the applications I want to study in a YAML file (https://github.com/tony/.dot-config/blob/master/.vcspull.yam...) and type "vcspull" to get the latest changes.
You can read my ~/.vcspull.yaml to see some of the projects I look over by programming language. You can setup your config anyway you want (perhaps you wanted to study programming languages implementations, so have ~/work/langs and cpython, lua, ruby, etc. inside it.
Michael's code looks clean and well organized. Shouldn't be terribly difficult for someone proficient at JS.
Once I've found and fixed a few things, or if the code base is particularly small or clean that I can't find bugs to fix, I'll set about hacking in the feature I'd like.
I usually start by doing it in the most hacky way possible. That sounds like a bad approach but it narrows the search of how to implement it and means I'm not constraining myself to fit the code base that I don't yet appreciate.
In hacking that feature I'll often break a few things through my carelessness. In then trying to alter my hacked approach so it no longer breaks stuff I'll become more aware of the wider code base from the point of view of my initial narrow focus. This lets me build up the mental model.
Eventually I'll be comfortable enough I can re-write the feature in a way more consistent with the wider code base.
I don't normally start by trying to "read all the code" because that guarentees I won't understand much of it (I'm not quick at picking up function from code). I might have a skim if it is well organised, but I find the "better" written a lot of stuff is, the harder it is to grok what it is actually doing from reading it. to me, reading good code is often like trying to read the FizzBuzz Enterprise Edition.
I've worked on many legacy systems: I was last year implementing new features into a VB6 code base, this year (at a different job) I am helping migrate from asp webforms to a more modern system. I've found that starting with trying to fix an issue to be the best way to dive into the code base.
Use good source control so you're never "worried" about changing anything or worrying that you might lose your current state. Commit early, commit often, even when "playing around".
As you read the code and encounter terms/words you don't know, write them down. Try to explain what they mean and how they relate to other terms. Make it a hyperlinked document (markdown #links plus headings on github works pretty well), that way you can constantly refresh your memory of previous items while writing
Items in the glossary can range from class names / function names to datatype names to common prefixes to parts of the file names (what is `core`? what belongs there?)
Bonus: parts of the end result can be contributed back to the project as documentation.
1. If it's on Github, find an issue that seems up your alley and check the commits against it. Or the commit log in general for some interesting commits. I often use this approach to guide other devs to implement a new feature using nothing more than a previous commit or issue as a reference and starting point.
2. Unit tests are a great way to get jump started. It functions as a comprehensive examples reference--having both simple and complex examples and workflows. Not only will it contain API examples but it will also let you use experiment with the library using the unit test code as a sandbox.
* Read the README.
* Install it and start using it with a couple of sample cases. That will give you an idea of what it does.
* Read the test suite. This will give you a better idea of what the library does.
* Look at the directory structure. This should tell you where things are.
* Start reading the core files.
* Start looking at open issues. Try to solve one by adding a test and changing the code.
* Submit a pull request.
While static typing helps a lot with this kind of exploration and navigation, I don't know of any IDEs or other tooling for any language that would really help you with it.Sure, you can probably generate UMLs or something, but it usually requires some additional tool and the output is pretty static. You can't just zoom in from a package-level view to an interface-level and then keep zooming until you are eventually shown line-by-line implementation of a specific function.
I've been thinking about this lately, and I've come to the conclusion that the way we think and reason about code is pretty far from the way our tools present it to us. I tend to think in terms of various levels abstractions and relations between units, yet the tools just show me walls of text in some file system structure (that may or may not mirror the abstractions) and hardly any relationships.
- find . -type f
- find . -name \* .ext | wc -l (get an idea of complexity)
- git log (is this thing maintained?)
- find . -name \* .ext | ctags
- find main entry points, depending on platform and language
- vim with NerdTree enabled
- CTRL-], CTRL-T to jump to browse tags in vim
Generally a lot of find, grep and vim gets me started.
Sure, this is not the best practice, and unsuitable for many, but it's what works for me.
We become fast friends and feel like we really understand each other.
But days pass, and each encounter feels less magical. It's almost like we having nothing in common. Like we're from two completely different worlds. One where its stuck in the past and one where I'm ambitious and excited about the future.
After awhile we don't really speak to each other anymore, and after some pretty ugly fights at work that get too personal... I rewrite it.
From my experience, there are really two ways that learning a new codebase can happen. One is that there's an existing test suite that's fairly comprehensive, and you can learn a lot by examining the tests, making changes to add features / make bug fixes, and then validate that work by rerunning the tests and adding new ones. That's really a great place to be as someone unfamiliar with a new codebase. The other is that there are no tests, and you inevitably need to rely on people familiar with the code, and make peace with the idea that you're going to write bad code that breaks things as you learn the depth of how the project works.
1. Just make sure I can build project;
2. Play around with services/application (just run, send some requests, get response);
3. Pick up simplest case (for example, some request/response);
4. Find breakpoints (for debugging) somewhere connected with this simplest case (for example, which stopped somewhere when I send request) and setup them in debugger. Usually, I find place where to put breakpoint by just searching keyword associated with my request;
5. Play around with these breakpoints while performing simplest case (for example, sending request) and try to find out call graph;
6. Try to change code and see what happens;
After I do this stuff several days/weeks, I become more and more familiar with the project.
A good way to get hang of the code base was to read it (usually using a tool like sourcegraph , pfff , open-grok , doxygen , javadocs ). Although a lot of people have argued that code is to be not treated like literature , but in this case, there was no choice.
The second step was to see if assumptions about the what the code does is correct. This is usually achieved by adding log statements, writing sample apps, and debugging in general.
Repeat the steps above, over and over again.
1. No matter what you do, you absolutely need to document everything you understand / misunderstand about the code base.
2. Never underestimate value of having a different pair of eyes look at code you have hard time reasoning about.
3. Be in constant search for resources (like books, blogs) available on the code / topic of your interest. You'd learn amazing amount by reading through other people's analysis. Stackoverflow is a great start. Heck, you can even ask well thought-out questions on Quora/Stackoverflow.
4. Hang out on related IRC channels / community mailing lists. For things written in esoteric languages such as OCaml, I found these to be pretty helpful.
5. You could blog about it, share the information you know over email lists, setup wikis; and people who know better would correct you. Its a win-win.
1) Read docs for how to USE the library if they exist
2) Review example code that describe how a person would use the library to accomplish tasks.
3) In order to start diving in, find a specific example that does something interesting, then hop in from there. Read the code within the methods / functions the user calls, then the functions / methods called inside those, etc.
4) As you dig deeper you may start finding that you understand, or you'll start building up your own hypotheses like "If I change X to Y in this function then something different should happen when I call it". Try it out, and see if your hypothesis is correct.
After a few iterations of doing something like this you'll probably start getting an idea of how the code is structured and where you'd need to go in order to make the changes you'd like to make, or add the features you want to add.
Every code base takes time to digest all the information. Sure the information passed your eyes, but is it committed to memory?
This can be especially useful for event driven code (looks like SlickGrid is jQuery-based, so that definitely applies here); you can start a recording profile, carry out the action you're interested in, then stop recording, and you can then find out exactly which anonymous function is handling that particular click or scroll or drag.
I just skim throught all the sources, then somehow I am able to point approximate file and line of code where a specific question might be answered.
This might sound "out there" but I realized during college I had the ability to recall the approximate location of specific information I needed from a textbox If I just skimmed through the whole book at the start of the semester.
For years I did this out of intuition, then about 10 years ago I took a course named "photoreading" and to my surprise they were teaching my "ability" but with clear steps so anybody could use it effectively.
For example I would start by looking up out a basic example of that codebase and for each of the function calls go through the files and see what is happening. This gives me an idea of how the code base is written and how it works. It also gives a clear understanding of the level of separation/specificity of the different functions.
Disclaimer: not very experienced so there might be better ways to familiarising ones self with a new codebase, this is just one way of doing it and it has worked for me in the past.
A couple of things that I typically do:
- Start with a fully working state, i.e. setup your environment, make sure tests (if there are any) are passing. If you can't get things to work properly, that's your first issue to investigate and fix.
- Don't try to understand all of the code at once. You don't need it yet. I'm assuming you want to take over the project for a particular issue. So just focus on that and ignore the rest of the code. If you ask any senior developer about something in their project, there is a great chance they will not remember the exact details, but know where in the code to look at. Aim to get at that level, not memorizing how everything works on the lowest level.
- Don't make any changes to the code that you don't understand. I have a recent example of this. Yesterday I was trying to find a bug in the Phoenix database, which was failing to start after an upgrade. I have never seen the code in my life. After some debugging I realized it's doing something with an empty string that shouldn't be empty. The obvious "solution" is to add an check if the string is empty and be done. Don't do that. Understand exactly why is the problem happening and only do a change like that after you are sure of all the implications. This has two effects, you are not introducing new bugs and you are learning about the codebase. At the end, the fix from my example was just a simple "if", but without understanding how is it ending up with an empty string, I might have caused more problems than I fixed.
- Use the VCS a lot when figuring our why something is done they way it's done. Use "blame" to see when things have been changed, read through the logs, etc. This is one of the main reasons why I don't like people rebasing/squashing their commits before merging. There is so much information they are throwing away this way.
- Adopt the coding style of the existing code. Don't try to push your style, either by having inconsistent style in different parts of the code or re-formatting everything. It's just not worth it.
- Don't be afraid to change things that need changing. There is nothing worst than making a copy of some module, call it v2 and then having to maintain two versions. If you are afraid to make a change in the existing code, make yourself familiar with the part of the code first.
You first have to localize a region (function) you want to study, then you reach one of its execution with a breakpoint, or a conditional breakpoint.
Then, you inspect:
- the callstack: in which condition the function was call
- the parameters / local variables
- the subfunctions: in both tools, you can manually call any (reachable) function, try different parameter values and check the result. Pay attention through to the side effects!
The first few mods are inevitably disgusting hacks, so don't pick anything you want to keep for your first couple of goals. It is pretty easy to go back and do them right once you've got your head around the rest of the project if you do end up wanting to keep them though.
TL;DR; Start with the minimum exposed surface area of the project (API), dig through these functions first. Definitely know the initialization sequences the library needs.
This is my approach concerning JS projects or for dealing with other peoples code in general.
First, I make a mental model of what I want to do. !important.Then I write the smallest wrapper needed to start fledging out points where "separation-of-concern" happens.
At this point I should have an idea of what the other persons libraries expose as API. I also should have an idea of what can be done with a unmodified library, and what would need patching.
Then comes monkey-patching the lib at individual function levels with a healthy dose of TODO markers and NotImplemented Method signatures.
By this point I should have a good picture of what goes on in the library apart from what gets exposed and would probably have forked a branch by now.
This strategy has been useful not just for JS projects but bigger codebases of java/scala libraries like Lucene Core/Solr or Play framework, Django in the python realm and to limited success with Research code releases like Stanford Core NLP.
Going a step farther still would be to add to the user documentation as you go...
Do something small, and iterative, and go out from there... for that matter, just getting a proper build environment is hard enough for some projects... automate getting the environment setup if it's complex. I've seen applications with 60+ step processes for getting all the corresponding pieces setup.
We generally approach it with heavy customer/owner involvement at first. We need to know what the application's intended purpose is. It is sort of like a lightening BA session. We get what the application should do, and what it isn't doing properly out of this session (and more importantly, what it should be doing instead).
Our first step: get it into a repo.
Now that we have an understanding of what the application's intended purpose is, we can dive into the code. We don't have any analysis tools (but if there are some that people could recommend, I'm all ears) outside of our IDE (Visual Studio). We generally look for the last-modified date as an indicator of what needed work most recently. Of course, we don't have file history so we don't know exactly what changed, but it gives us a rough idea of what was worked on and when.
Next we usually try and use the application in our development environment. We chase each action a user takes in the code to determine what is the core/central part of the application. After that, we try to determine the cause of the problem (and while we are at it, we generally do a security review of the code).
It takes time, and is painstakingly nuanced and very boring. But I'm not sure what other options we have in such cases. As I said, I'm all ears as to what other might do in these situations.
First, we read the Native Client papers (http://www.chromium.org/nativeclient/reference/research-pape...) to understand how Native Client sandboxes untrusted code. We then looked at the tests in the Native Client source repository to see how to run untrusted code within a Unix process. We're yet to be able to debug executables via GDB for reasons we don't quite understand - so at present we:
1. Set NaClVerbosity to 10 and trace the system calls and functions invoked in the tests2. Run "grep -r" in the src folder to find the source files for each of the functions invoked then read and understand the code for each3. Insert our own calls to NaClLog in the source code to read the state of variables and to validate our hypotheses of paths of execution within Native Client
For example, just this afternoon we found out how to send data via inter-module communication instantiated from the trusted code to the untrusted code. We first thought this wasn't possible - and that communication had to be initiated from the untrusted code, handled in the form of a callback function in the trusted code. However it simply turned out we had set the headers incorrectly in that the first four bytes of the header should be 0xd3c0de01. What's crazy is that we haven't yet understood what these bytes mean - so we're back in the Native Client source code to try and see why it works.
This probably sounds like a rant about Native Client and the Native Client developers. However, the complete opposite is true. The folks on the Native Client Discuss forum have been very helpful and have been more than happy to answer our questions. Quick shoutout to mseaborn: thank you for your help!!!
If you have access to logs from a production service / component, I find TextAnalyzer.net quite invaluable. I take an example 500 mb log dump - opened in TextAnalyzer.net and just scroll through the logs (often jumping, following code paths etc), while keeping the source code side by side. This allows me to understand the execution flow, and is typically faster than attaching a debugger. If it's a multi-threaded program, the debugger is hard to work with - and logs are your best friend. You are lucky if the log has thread information (like threadId etc)
In your case, frozen columns seems to be a hard feature. So I would start with ajax data source. I'd start with a simple SlickGrid example and get it to run. Then go find how SlickGrid sets up data source. Expand that piece of code to add ajax data source. Once I finished ajax data source, I'd dig into frozen columns.
If you are working on a new codebase and worry about bugs, you just give yourself more stress. Bugs (that are not yours) are expected. If they aren't blocking your task, ignore them. Most likely, they aren't relevant to what you are trying to do.
I include function names and the names of the variables passed as parameters. But, no braces or other syntax. Almost always omit branches/variable decls/error checking. Include all interesting function calls along the path, but omit any branches/function bodies that lead off the desired path. Inline callbacks as function calls with addition notation. If the process has separate steps that aren't a single call/callback tree, start a new tree with the note "then later..."
To do this, I have to start from the line of code that enacts the outcome and determine the backtrace with a combo of debugger stack traces and examining the code for branches/callbacks of interest.
But, when it's complete, I'll have the start-to-finish process of some complicated task in the code --usually on a single screen of text. It's a tremendously better use of my short term memory to scan over that than to constantly bounce around the actual code base.
Thisd make a great contribution already: SlickGrids codebase is somewhat poorly documented, which is a barrier to the involvement of interested developers.
As you write the docs weak spots in existing implementation will come to your attention, helping you figure out what to fix first.
One downside is that writing down and structuring your knowledge in easy for others to grasp way is a challenge in itself, though arguably a useful exercise.
Once I know what the data is I can look at the code with an eye towards maintenance of data integrity. I might still need some "playtime" to grok the system but the one truism of large software is that data is always getting shoved from one big complicated system to another, and I can usually identify boundaries on those systems to narrow the search space.
(the exception to this is if you have code that leaks global state across the boundaries. Then much swearing will occur.)
As you start to add to a project the IDE can also prove valuable in discovering how everything fits together, since it will provide smart and helpful completions with docstrings, method signatures, types etc. This can really help you start writing new code a lot faster.
Also, an IDE will usually also have a decent UI for running the code with a debugger attached, which can be incredibly useful for understanding the changing state of a running program.
If the problem is some bug and there are stack traces that is my starting point, debugger and a few breakpoints chosen from the trace and then follow the stack and from there I start knowing how it is structured, and then the next bug and so on (fixing them of course)For code where I need to add features things get a little more tricky, but there is always some entry point, a web-service invocation, some web page, and try to understand what it is currently doing, again using the debugger to follow the calls and how the data is changed (sometimes even going into libraries).
Reading the docs if there are any is also a good place to start.
Once again, use the debugger a lot, makes it easier to understand than just reading the code.
While it is focused on CPython, most of the techniques are applicable elsewhere. It also mentions a great article by Peter Seibel (http://www.gigamonkeys.com/code-reading/) that discusses why we don't often read code in the same way we would literature.
Essentially, as the complexity of software has grown people have been forced to take a more experimental approach to understand software even though it was created by other people.
> What tools and techniques do you use for exploring and learning an unknown code base?
One thing I do NOT recommend is changing the code style, unless you're ready to take full ownership of the project. It can make it much harder for the project owner to merge in and if there are any lingering PRs those will typically need work to merge in properly.
The first read-through is not about comprehending everything. It's about exposing your mind to the codebase and getting it to start sinking into your subconscious. It's kinda like learning a new piece on the piano.
If you're looking at a large Go codebase with many packages, I find it helpful to visualize their import graph with a little command .
Here are results of running it on consul codebase:
$ goimportgraph github.com/hashicorp/consul/...
1. Access some data in the highest level component from one of the lowest level components
2. Access some data in one of the lowest level components from one of the highest level components
In a lot of cases, good architecture will prevent one or both of these from being possible, but identifying how data flows through the app seems to be a good way to understand the general architecture, limitations and strengths of most apps. These two tasks give concrete starting points for tracing the data flow.
I'd try to fix it using the same style used in the codebase. This way anybody else reading, maintaining ,or using it won't have to make sense of the new style. Pay attention to how each method is defined. They are very readable. Very few traces of complex one line statements.
Most importantly, be patient. You won't be any good with it in less than 2 weeks of constant tinkering. Good luck.
Then I run the app and put it through its paces, while watching the output in another console.
If there's some code that doesn't make sense, I use console.log() heavier in that section, to help me fully understand what it does. Once I have that level of understanding, I then write some comments in the code and commit them so that other contributors may benefit in the future.
Programming with unit tests really helps. And it points out where certain parts are too entangled and bound to implementation.
I think reading each file or reading the data structures is more difficult because you have no familiarity as to what is going on and you have no knowledge of why things are structured as they are, so it'd end up like reading a math paper straight down: memorize a ton of definitions without knowing why, until you finally get to the gist of it.
I search for strings that appear in the frontend (or generated HTML source, or whatever), and then I use a search tool (git grep) to find where it comes from. And then I the same search tool again to trace my way backwards from there to where it's called, until I find the code that interests me.
And then I form a hypothesis how it works, and test it by patching the code in a small way, and observe the result.
Oh, and don't forget 'git grep'. Or ack, or ag, or your IDE's search feature.
Then I prefer to jump into fixing any existing issue. Working on fixing an issue teaches a lot, more fixes, then features, rinse, lather, repeat.
While this post talks about fixing compiler bugs, the overall steps are much replicable: http://random-state.net/log/3522555395.html
Start from main() and start from the one click event(or any end-game action). Try to connect the two.
Generally I find it hard to just start reading through packages, source, functions, etc. and find it much easier to try and solve some sort of problem. By tracking and debugging a particular issue through to the end, I find a learn a lot about the codebase.
The Ruby application server I looked at was for doing social network feeds. Posts/Likes/Comments go in, feeds come out.
I followed some common code paths for things such as posting a comment and getting a feed. I would write the stack trace down on paper as I went.
It also helped that I happen to know that this ruby server used wisper and sidekiq. This way I didn't overlook single lines of code such as 'publish: yada yada'
People really do learn quite differently and everyone needs to find their mode of learning - there is no one single true way. This is one of the most important skills in software development, IMO. Once you learn how you learn you can apply it to most new contexts.
I write stuff down because for me that-the process of writing seems to be the most effective way to learn.
I'll start reading the files using any of the strategies mentioned here and looking for things I can cleanup. Formatting, Simple Refactors, Normalizing Names.
These are all things that are comparatively easy to do and safe but force you to reason about the code you are reading. Asking yourself what you can refactor or fix the naming for is a deent forcing function for actually understanding the code.
Some people use graphical tools to visualize a codebase (e.g. codegraph). It can help you understand what pieces of code are related to each other.
Simply digging through code, tests or reading commit messages in an unfamiliar code base takes at least an order of magnitude more time.
EDIT: tried call graphs too, better than reading through code, but still require you to understand and filter out a lot of unnecessary information.
I'd like to print out a big graph and stick it to the office walls so I'll have a good view of the logical structure.
You do not need to familiarize yourself with the full codebase at the start. It's too time-consuming and mostly not worth the effort. Set up an objective and go for it slashing your coding axe around until it works.
: Unless you have an special interest or you are assumed to familiarize with the codebase.
My typical strategy is to get the project running, then just get to work. Start fixing bugs, and adding requested features. Use the code around you as a guide on what is right and wrong within that company, and forge forward. When you are unsure of something turn to grep, find some examples, and keep going.
Take the extreme programming approach. Don't try to familiarize yourself with a new codebase all at once. Start small. Work on a small ticket. It will, organically, help you assimilate what's happening.
Try to fix a bug and you'll soon find yourself having to learn how the code involved works, and with a goal your focus will be better than just reading through the code flow.
This is probably not the best way to approach this, but I am somehow ADHDish and I need a clear task to avoid perpetual diving in the codebase.
something usually comes up.
Then I write unittests
Like changing some function like:
Text -> Text -> IO ()
ServerHost -> Path -> IO ()
In any language I'll try to read the project like the Tractatus.
In stuff that isn't Haskell? Break stuff and run the tests.
- Get a functional dev environment set up where you can mess around with things in a risk-free manner. This includes setting up any dev databases and other external dependencies so that you can add, update and delete data at will. There's nothing that gives more insight than changing a piece of code and seeing what it breaks or alters. Change a lot of things, one at a time.
- Dive deep. This is time consuming, but don't be satisfied with understanding a surface feature only. You must recursively learn the functions, modules and architecture those surface features are using as well until you get to the bottom of the stack. Once you know where the bottom is you know what everything else is based on. This knowledge will help you uncover tricky bugs later if you truly grok what's going on. It will also give you insight as to the complexity of the project (and whether it's inherent to the problem or unnecessary). This can take a lot of time, but it pays off the most.
- Read and run the tests (if any). The tests are (usually) a very clear and simple insight into otherwise complex functionality. This method should do this, this class should do that, we need to mock this other external dependency, etc.
- Read the documentation and comments (if any). This can really help you understand the how's and why's depending on the conscientiousness of the prior engineers.
- If there's something that you really can't untangle, contact the source. Tell him what you're attempting, what you tried, exactly why and how it's not working as you expect, and ask if there's a simple resolution (I don't want to waste your time if there's not). You may not get an answer, but if you've done a lot of digging already and communicate the issue clearly you might get a "Oh yeah, there's a bug with XYZ due to the interaction with the ABC library. I haven't had time to fix it but the problem is in the foo/bar file." You may be able to find a workaround or fix the bug yourself.
- When you do become comfortable enough to add features or fix issues, put forward the effort to find the right place in the code to do this. If you think it requires refactoring other things first, do this in as atomic a manner as possible and consult first with other contributors.
- Pick a simple task to attack first, even if it's imaginary. Get to more complicated stuff after you've done some legwork already.
There are other minor things but this is generally my approach.
My dayjob is with a Ruby on Rails consultancy. Said dayjob involves familiarizing myself with a lot of different codebases. My strategy here is rarely to try and digest the whole codebase all at once, but rather to focus on the portions of code specific to my task, mapping out which models, controllers, views, helpers, config files, etc. I need to manipulate in order to achieve my goal.
The above strategy tends to be my preference for most complex projects. The less I have to juggle in my brain to do something, the better. I tend towards compartmentalizing my more complex programs as a result. For simpler programs (and portions of compartmentalized complex programs), I just start at the entry point and go from there.
Languages with a REPL or some equivalent are really nice for me, especially if they support hot-reloading of code without throwing out too much state. Firing up a Rails console, for example, is generally my first step when it comes to really understanding the functionality of some Rails app. For non-interactive languages, this typically means having to resort to a debugger or writing some toy miniprogram that pulls in the code I'm trying to grok and pokes it with function calls.
For some non-interactive languages, like C or Ada, I'll start by looking at declaration files (.h for C and friends; .ads for Ada) to get a sense of what sorts of things are being publicly exposed, then find their definitions in body files (.c/.cpp/etc. for C and friends; .adb for Ada) and map things out from there. Proper separation of specification from implementation is a godsend for understanding a large codebase quickly.
For a rigorously-tested codebase, I'll often look at the test suite, too, for good measure. When done right, a test suite can provide benefits similar to specification files as described above; giving me some idea of what the code is supposed to do and where the entry points are.
We have to setup custom filters for all of these. Google does have a feature to automatically remove know sources, but it's not turned on by default. Here's the announcement: https://plus.google.com/+GoogleAnalytics/posts/2tJ79CkfnZk
We also run Piwki on all our client's websites as well and they block this junk automatically: http://piwik.org/blog/2015/05/stopping-referrer-spam/
We will soon start working with this new analytics tool - Kilometer.io that will most chances be very good tool and a nice competitor.They now have this beta waiting list for a month at - http://www.kilometer.io
If all you want is printf and friends then you can probably get started that way.
We have built a ride share matching system:
Our goal is to make use of unused seats in cars matching drivers and passengers. We do not put any cars on the road (i.e Uber), We match to drivers on their daily commute.
Our Biggest Problems:
1. We are quite successful at converting people who are posting to online classifieds etc. We have strategies to get these users. We grew week on week by as much as 50% but then we hit a negative growth week. In order to continue growing, we need to expand into other areas.
We also have an un-balanced market. Demand for rides is much higher than rides offered.
2. We have not figured out how we will make money yet. Our initial hypothesis was a transaction fee.
The passenger and driver will be traveling together on a regular basis. Once we match them, we run the risk of being dis-intermediated.
You could make an argument that a payment directly into the bank account is more convenient than cash, though i am not sure that is a strong enough incentive.
3. Our churn/attrition is very high, There is no need for the system once they start traveling together. We have churn built in to our model.
May be a bit out of your area, but I'm curious about your thoughts. Even though we are in "Silicon" Valley, there has been very little when it comes to new semiconductors investments. I'm the co founder and CEO of REX Computing (http://rexcomputing.com), a new semiconductor startup working on a super energy efficient processor architecture. We've actually raised seed funding, and I'm interested in what you think about the semiconductor space in general (and its future in the valley), plus ideas on how we can thrive as a very low level hardware company in a primarily software world.
Edit: One other thing I should note is that we are also big on software! We're utilizing a lot of open source projects to help build up our compiler and other software tools. Obviously hardware without software to run on it is pretty useless.
Pitch: We're replacing congress with voting software. We are running 70 candidates in the 2016 Congressional elections on our platform, if any of them get voted into office we'll take all bills before congress and put them on our site where each voter in that district gets one authenticated vote.
Question: In your experience, what's the most effective way for B2C company to educate users that you even exist?
I know that signups and conversions are an art, but more than all of that, just telling people that you have something new that they may not be searching for but could still dramatically improve their life. We will take any demographic that will have us, so we aren't picky on that front.
We have 100% week-over-week growth during election cycles, and 10-20% when it's not, so we know the message is received, we just want to get more people in the top of the funnel.
The potential market for automated micro-farming (backyard farming) is huge, but it will take a long time to to reach its potential. My question is, at what point would AutoMicroFarm (http://automicrofarm.com/) become attractive to investors (both YC and others)? Would 10% weekly growth for a year be key, or something else?
Two and a half years ago, we AutoMicroFarm founders had an interview with you, and you decided not to invest, saying it was difficult to see how AutoMicroFarm would generate the kind of growth startup investors are looking for. However, YC invests with infinite time horizon and is not afraid of risky-looking companies (http://blog.samaltman.com/new-rfs-breakthrough-technologies).
So what would YC or other investors like to see before investing?
We are building a platform that allows anyone with a mobile phone to earn a living by performing discrete tasks.
Our platform aims to break down complex jobs into easily actionable items, that can be performed easily by anyone, anywhere.
The first vertical we are applying this to is reservations. The Loft Club (https://useloft.com) is a service that makes reservations for you at amazing restaurants every month on your preferred day, saving you the decisions and the hassle. Through our platform, we centralize restaurant recommendations and assignments, before farming out the logistics of making and manging them to our agents.
Our question is: Should we work on building out the generic platform and expand quickly into other verticals, or focus on building out The Loft Club and owning this space first? We've customers paying us for The Loft Club with the mild publicity it has received thus far.
Zhuang and Derrick
ZeroDB is an end-to-end encrypted database that lets you operate on data while it's encrypted.
Demo video: https://vimeo.com/128047786
Question: We want to sell to large enterprises (financial services, healthcare, saas providers, etc.). The common advice is to start with SMBs/startups and get traction that way before going upmarket to enterprises. How can we balance that with the fact that what SMBs are asking us for is very different from what enterprises have told us they'd like in a fully-baked product?
We are about to finish building a table reservation system (think OpenTable or SeatMe but on steroids). Although it's a "Me Too" product, we will offer features that our competitors can't or won't, e.g. bigger API control for restaurants, various hooks to extend the service such as food delivery, pre-paid reservations, and ticketing for tables to name a few. Essentially, we will offer an iPhone/iPad app for restaurants to manage their reservations/orders, while their guests can use an iPhone-app/Android-app/Search-Engine/Restaurant's-Website to make those reservations.
I have a question about a launch/pricing strategy:
- Is it sane to do a freemium model for our product? For example, restaurants would be able download our Manager app in App Store for free but it would have limited offline features. If restaurants want to accept online orders, then they must get that feature via in-app purchase. If restaurant wants to incorporate discount cards, then it's a different in-app purchase. This logic applies to all different features.
- Or should we go through a regular sales process, i.e. sign up restaurants one-by-one, charge them via check/credit-card/etc and escape Apple's 30% cut?
Thanks in advance and I hope it will be helpful for other startups that are in a similar position.
Were MinoHubs (https://www.minohubs.com) and we build commercial and community tools for software projects. The barrier to building a successful software project is high - apart from writing the code, you need to build a community and potentially set up some commercialisation (backing, licenses, support etc.) which isnt an easy task.
We provide customizable hubs that give projects:
- Paid support - ability to offer on-demand consultation to businesses and developers.
- Licensing - ability to sell one time and recurring licenses to businesses and developers (coming soon).
- Backing - monthly contributions. In return, backers get more visibility in Discussions.
- Powerful discussions with voting.
- Announcements - emails and notifications to project followers.
From Kevins initial feedback (https://news.ycombinator.com/item?id=9746206) we understand that we need to be better at:
1. Leading the user through things to do after creating a hub.
2. Showcasing the benefit of using MinoHubs.
Were working on those right now.
Our challenge is that, as Kevin also pointed out, we have a lot of features, but were also trying to appeal to an audience that would use different combinations of features; open source software, commercial software or projects that want to just use community features.
How do we reconcile that users want a wide variety of functionality with the issue that this might present too many features for us to convey concisely?
Coincidentally we started sending out beta invitations last night to the first group of people on our list before a planned public launch next month. Our recommendation engine is built on Google App Engine, which should (we hope) allow us to scale. My office-hour question for Sam and Kevin would be: What advice do you have for us at this stage?
What we do:
We're building a community of vehicle data (http://shadenut.com). Mechanics and DIYers will be able to look up any piece of information they need to work on their car directly from their phone while still under the hood (ex. torque specs, TSBs, fluid types/capacities, etc). As a developer I've seen the positive effect that StackOverflow has had on our industry as a knowledge base and am trying to do the same for the automotive industry. The data will be crowdsourced and 100% free to use.
Our biggest problem is that the product is not really usable unless it contains EVERY piece of technical data about a model, after which it becomes tremendously useful. The most common feedback we get from technicians is that they'd love to use it and contribute once it's a complete database (as long as it's accurate) but wouldn't switch from the paid competitors until then. The data is all available but there's simply too much of it for a small team to manually import. Our current strategy is to start with a select few models and incentive technicians to make their own entries.
However, I'd love to hear how Kevin and Sam would solve this or from others in the HN community who have faced similar problems.
I have a solid engine, nothing launched yet.
My question is: why would you not fund this project right now? What could I do to improve my odds of getting funding?
Pitch: We're ATLAS, we plan to launch extremely small cubesat payloads (x<100kg) into low earth orbit on demand.
1) How much calculations/numbers crunched would we need to convince angels to invest? Rockets of this size aren't something we can bootstrap without a little financial support.
Right now, the only way to get a cubesat into orbit is by ridesharing on bigger rockets as a secondary payload. The problem with this is they're not assured to reach a preferred orbit and are at the mercy of the scheduling of the primary payloads. NASA currently has a backlog of ~50 cubesats that need to get into orbit, as well as the many upcoming launches (including SpX this Sunday). We are currently working on the RFP for the Venture Class Launch Service however we may not have the resources to fully complete it by the deadline (13 July). We plan to market this service to Universities as well as hobbyists and government space agencies.
Help needed - We think that either the government or certain enterprises will pay for this data (since they already are spending money on such technology). What is the best way to validate these channels?
ACe here from Painless1099 (www.painless1099.com). We automate tax withholding/filing for anyone earning 1099 income (think: freelancers and Uber drivers.)
We're thinking through growth specifically right now and are chewing on whether to go the B2B route or the B2C route. Different implications for both regarding scale and revenue obviously. We'd be stoked on a bit of help figuring out which to tackle first and how to make headway!
My strategy thus far has been to find startups that need help doing their devops and help them automate their deployment using Tasqr. Finding customers this way has been slow, but I've gotten to learn quite a bit about how the product fits within a continuous integration workflow. I am starting to feel a little financial pressure to change my approach and scale my outreach, though my existing users really like my "do things that don't scale approach" unsurprisingly :-)
What are some signs that it's the right time to scale and chase bigger chunks of the market?
Today, this market niche is fragmented with high search costs for consumers. My marketplace will make it much easier for consumers to find and buy the products this this niche. Once off the ground, the marketplace will be a key source of customers for the merchants.
Consumers like the product, but the merchants are difficult to get on board. I find that the prevailing view is that the status quo is 'good enough'; merchants are conservative, and very few are early adopters.
Things I'm doing to address this:
1) Price for growth -- pricing based on a small flat fee that the merchant pays per transaction to align with value delivered, with first X transactions free (obviously I would prefer to charge a % of revenue, but that's a very, very hard sell with these particular merchants).
2) Provide the merchants with tools that help them run their business (i.e. give them reasons independent of the marketplace to use the app)
3) In-person visits to merchants. These are valuable for many reasons, and are only partially a sales call. These visits will always be something I do, but it doesn't scale enough to create a marketplace.
What strategies and tactics do you suggest to get merchants into the marketplace, to build up the supply-side?
We built ObjectiveFS, it's like Dropbox, but for servers. We have users running our shared file system in production, and are getting great feedback.
Our current challenges are user growth and upcoming competition from Amazon EFS.
We would like your feedback on what we can do on our website (http://objectivefs.com) or additional things we can do to get more people to start our free trial and to address the Amazon EFS competition.
About a year ago I created an eSports app that lets fans of the game DotA follow and watch their favorite teams live and on the go. It's been super fun seeing my side project grow and have users in the community volunteer to help with designs and language translations.
The biggest tournament of the year (http://www.dota2.com/international/announcement/) is coming in a few months and I would love to talk about different ways to capitalize on this.
I'm thinking about starting a company that extends the open-source concepts to the biology/pharmaceutical sphere. The concept is to make a modular, drug-producing microbial strain, and release that to researchers/industry under a permissive licence (e.g. bio equivalent of GPL). Monetization comes about by offering manufacturing services which cut the pain of 1) scaling and 2) getting "good manufacturing practice" regulatory clearance for clinical testing, and ultimately full consumer product.
Do you think there's VC interest in funding these sorts of ideas that have a somewhat riskier business model that also ultimately will extract a lower margin, but has a chance of changing the "way things are done"?
we are Tiedots (http://tiedots.co), a networking platform that provides you tailored information about other attendees every time you go to an event. This way we unveil you the most valuable leads and also find you the best way to approach. Saving time and increasing your business opportunities
The biggest challenge so far is building a solution that can provide relevant connections. Accuracy is the key and were working on a web semantic solution since weve been testing the solution manually with around 100 event attendees.
How would you determine the relevance? any other ideas?
PS: No matching solutions. Networking is about leads no matching.
The problem: our focus is divided on two types of customers (weve even created two landing pages for each type)
1. Product/Engineering teams - they get asked a new question every day that attempts to keep tabs on the health of the project. Questions are a combo of post-mortem style questions (but asked as you build product) and around prediction markets (larger n make better predictions) (https://www.getsubcurrent.com/product)
2. HR/Employee Engagement - users get asked a well researched question every 2 weeks. Instead of long, annual surveys, you now get to keep a pulse on morale and culture. Participation is higher since it only takes a single click in your already existing tools to respond. (https://www.getsubcurrent.com)
We have a number of customers using our free beta - most are using it for option #2. A very small number have connected with #1, and while we think it has a lot of promise, we havent talked to enough people to know how it might need to change to achieve product/market fit. We are at a crossroads of needing to pick one to focus on, because the distraction is making it difficult for both to progress.
We built a prototype last week and went to stores and a retail conference this week. We are having problems convincing stores to adopt out product as they are very concerned with shoplifting.
I am the creator of https://www.spqrs.com
The goal of Spqrs is to have a platform for the debate of ideas. As Sam noted in https://twitter.com/sama/status/610494268151431168 most smart people are wary about commenting on sensitive issues.
This is unfortunate as the Internet is a great place to discuss issues with people who may have a vastly different view, and in the process really examine why you think the way you do.
Spqrs provides a service similar to Twitter but allows you to follow hashtags as well as people and has a 1000 character limit instead of 140 better allowing you to make a point. The defining feature is that all usernames are pseudonyms so you can avoid threats to yourself or your livelihood based on what you say.
Right now this is a pay service. I am planning on charging $9/year. My biggest problem right now is finding subscribers. Any feedback and suggestions would be appreciated.
We're from Mise. We are an online marketplace and meal delivery service for the signature/best dishes from professional chefs in the Bay Area. Theres a face and a story behind each dish. We do free weekly delivery to SF Bay Area, including San Jose & the Peninsula.
We operate on a revenue share model. Chefs source their own ingredients, pay for kitchen rental, cook dishes, and earn 70% of everything they sell. We apply our 30% towards delivery, personalized packaging, copy, and kitchen administrative fees.
We'd love to talk about obtaining that 10% week over week growth. We're launching in 2 weeks and have a lot of orders (but a good amount are on us and going out to influential members of the community). How do we grow that into paying customers? And is it too risky to keep giving out free product that when you have to also balance the returns of the suppliers/chefs themselves?
I'd like to discuss two things:
1- Signal vs Noise in online communities: Since you've been heavily involved in Reddit (Sam), I'd like to know how what your opinion in curating content vs. having an algorithm sift through the noise. We see companies like netflix and ph (allegedly?) combining big data with human curation and having a lot of success, so my question is: Should online communities invest in curation or big data? Is there a trend towards one or the other?
2- Monetisation: I'm having a hard time monetising this community. Since I'm looking to bootstrap it, its crucial that I get monetisation right so I was wondering if you had any tips on monetising communities?
We provide a free solution for event organizers who are tired of doing customer service to their attendees by embedding our widget as easy as embedding a YouTube video. Other conferences have already hopped in like Traction Conf, check it out in action: http://www.tractionconf.io/accommodations
Let's just say that getting more events one by one isn't hard and our next step is to partner directly with ticket providers (SeatGeek, Ticketmaster) and do some sort of revenue share deal on accommodation sales.
Brief overview: I would like to market local, weekend yoga retreats to professionals in the oil and gas, energy, and finance industries. No long absences from work or family, and no long-distance travel. The startup is set up in Houston, but can operate in any city in the USA. Lots of different marketing and advertising methods are being tried (online groups, directories, online forums, linkedin, etc.), but I am pretty much throwing things to the wall and seeing what sticks. Any suggestions are appreciated. Thanks!
startup: bodyhugs: hug your body with movement and care
local health and wellness retreats in the USA
The team right now is investing itself in areas such product, marketing, and architecture. We want to launch a product so we can begin testing our hypotheses, but we also want to go to battle sufficiently prepared. The latter requires significant effort in team building, which would detract from a product launch. What should we do?
Problem: People generally buy web hosting once every few years and there are very few channels beyond Google and word-of-mouth to capture people at the moment they are considering purchasing. The competition for Google is astronomical (one of the highest PPC areas at ~$20/click). Organic rankings are filled with spam sites touting the highest paying companies with very good SEO (Hello CNET). I've been trying for years to get my SEO up to that level without success. I'm stuck on 2nd/3rd page and have been for ages. It's like purgatory, I've tried build other sources of traffic through PPC, CPM and none have really panned out that well. I've tried creating great content and it has been ok in some niches. For example, for high performance WordPress hosting information my blog has become the go to source. I'd like any ideas on what I should be trying to do next or what I can do to improve what I'm currently doing.
I am the founder of https://ManualTest.io. My app automates manual testing. It generate and run integration tests by recording and replaying users' actions on their websites. Manual testing is still being used everyday (by developers or not), so this could be a huge time saver for them.
My app is recently available on the Chrome Web Store, it only got a few users, despite having quite positive feedbacks. My question is, I am not sure the lack of users is because (1) I haven't done enough marketing/SEO/etc to get it in front of people, or (2) because I need to build more features before users would find it useful enough to try, or (3) it is just not something users want.
If its (1), I should stop coding and start focusing on letting people know about my product. If it is (2), I have a few very useful features that are still waiting to be done, but they could take at least weeks to complete. Without enough initial users, I am not sure which features users want most, or if the current set of features is enough for now, so I should focus on letting users know about it (so it is (1)).
The goal is to scale it across the US (and beyond, to any english-speaking area). Doing cost-effective marketing is key. How do we get the word out? How do we improve the site and experience so much that players tell their friends?
We put effort in SEO building a large database (the largest?) of string and racket specs with the goal of attracting some of the core fans of the sport (we started to get some clicks a day). There are a ton of other "social" and related ideas, the question is how to select which one(s) will work best.
Question: We have an awesome product that schools love. It's time to sign up as many middle schools and high schools as possible before the new year rolls around. As a one or two man show, what advice could you give about approaching these schools and how to expose our product to this market? Thanks!
Background: I'm building freedom.biz, which is currently a course for retail business owners who'd like to take their business to the next level. I sent out a survey to those on my interest list, and it became clear that I couldn't personally fulfill all their needs. However, I know people who can.
I'd love to build a company that connects vetted experts with the business owners who need them. I've seen startups in this realm, but they all feel generic and unfocused. What do you think would be a competitive advantage in this realm? What would you like to see that's not out there right now?
Hey guys,Our platform unbundles apps' and websites' most essential features and transforms them to interactive Cards. Similar to Google Now Cards. However the entire architecture is designed to be an open platform. Meaning anybody could come and build these interactive cards using our Language, REL. We believe, by unbundling Applications/WebService we can seamlessly start connecting different pieces of the web together, and create a more fluid and unified internet experience. An experience with an intelligent fabric that grows with our needs, preferences and expectations to help us make the right decision, at the right time.I'd love to hear your thoughts on Relevant. Thanks!
I think that the next big step in Medical Technology will the the rise in software making medical decisions. This doesn't pose a big technological problem but it does pose a large regulatory problem.
I have experience getting cloud-based software through the FDA as a "medical device" and have overcome some of the most common hurdles.
I have an idea on how (and the ability to implement) a product to reduce the regulatory and monetary barrier to entry for this type of software.
My question is, in the current market, does this have any shot of getting funding? The product could never be used without the approval of the FDA, an expensive process. Is this a non-starter for most funds?
Question: how do we sell this to investors? I'm a designer and the CEO. I'm good at making a product that people love but I'm bad at fundraising. We are out to make only high quality products, another hard sell to investors because high quality takes more time (money).
We have a great product that fans will absolutely love, we just need help getting it out there.
We made a trivia gameshow for mobile devices. Everyone plays simultaneously once-a-day at 11AM PT / 2PM ET. Players see the exact same questions, so it's like a live, multiplayer, interactive version of traditional gameshows on TV.
We have ~300 MAUs and ~50 DAUs and solid retention, but to get that up to 1,000 DAUs should we be more focused on trying to trigger organic sharing within the app or top line from press, blogs, reddit, Facebook ads, etc? Is our user base too small to even know whether our organic sharing is really working?
Pitch: Our application decreases labor costs by precisely scheduling hourly employees to fulfill business demand. By preventing over and under-scheduling, we've been able to show a 10% decrease in labor costs with early customers.
Question: What wisdom do you have about "go-to-market" strategy in the retail space? We have startups as clients that are eager early adopters, but to cross the chasm to sustainable growth it seems that we will have to focus on retail companies and going to many trade shows. What can we do now to prepare?
We are working on a new version of http://www.muusical.com. The new version is a significant change. It is going to be a free Spotify that is powered by a crowdsourcing platform where users add the music and meta data.
I would love feed back about a strategy for approaching investors who are wary about music startups.
If you're interested, read more here too: https://angel.co/muusical
iOS Download link: https://itunes.apple.com/us/app/i-boating-gps-nautical-marin...
Our biggest pain point: Distribution
Memaroo is a web research dashboard, designed to make iterative web searching organized and more efficient. Memaroo records your search history into different projects, which can be accessed from anywhere -- so you can search for things on your phone and then continue your research later on your desktop. Projects can also be shared with other users, allowing collaborative searching and result sharing.
Memaroo is an improvement to an established search paradigm. But people are comfortable in that paradigm, despite its flaws.
How can I get potential users to break their existing search habits and try something new and possibly better?
We are CodePicnic (codepicnic.com), a platform for sharing, running and showcasing code through a browser. We help people and business improve their demos, APIs documentation, or anything that needs for their users to run and try some code online.
We'd love to improve our "getting there" process. We've been interacting with users here in Hacker News, Reddit, Product Hunt and other sites, and getting better and increasing our usage, but still we feel is not enough right now. Our first users love us, the service and the potential, but perhaps there's something glaring we aren't doing well in order to be more well known. Is a long process, we get it, but the more we learn, the better.
I also believe this is an important matter that many other startups would love to learn about.
One of the problem I am facing is how to pay them back? And how to checkout if the view was genuine or was done by some bot?
Sorry to all if this comment is inappropriate.
Office Our provides a portal for investors to interact with their top 5 potential investments. "Separate the wheat from the chaff."
At Office Our an investor creates a post (or "bulletin") inviting the community to pitch their startup. Users vote on the "wheat" and the top 5 earn the right to receive a response. The investors can then manage their bulletin and follow-up outside of our platform.
For this we charge a simple, flat $5 fee to each investor per potential investment per month on an annualized basis in the form of credits which are distributed by each of the user's votes in batches of baker's dozens. "Investing - simplified"
I look forward to your feedback.
1. Go to YouTube (or Vimeo).
2. Search for "Alan Kay".
3. Watch any video that is longer than 20 minutes.
Repeat for "Leslie Lamport" and then for "Rich Hickey".
A life partner, one not afraid to get their hands dirty doing what needs to be done for a vision outside the mainstream paths, grow with them through the fails and the folly, and experience two lives in one lifetime. Find someone to remind us of why to be humble through the successes that can blind one to appreciation and the efforts of others. Someone who does not see us for success gotten, but for the inevitable happiness and richer gain from a partnership with an equal of good character.
Children, to see the world through innocent and new eyes. To see value in things we take for granted, and to give us a reason to think of the future as a prospect even though much of our prospecting years may now be behind us.
It has never been a better time to be poor. What we risk with all the other wins beside family is a life without riches. With others we can know ourselves better, be more whole, understand what makes us human and what drives us to betterment of ourselves and humanity.
The ups and downs of life is the most enriching experience, to know genuine empathy and share sincere hopefulness. One can find such experience in family.
While your life might totally suck beyond what you could ever have ever imagined, after a point there is a sort of humor to be found in the absurdity of it all.
Failure becomes an afterthought, because it simply means ending up right where you currently are - the bottom. This is the classic "nothing to lose" dynamic working in your favor.
Counter-intuitively, the opportunity costs involved seem to matter less and less the more your career and family prospects dwindle. In a weird way, that can be liberating.
However, such thinking can be extremely destructive. It's essentially tantamount to starving yourself as a means of motivation, while at the same time applying a Martingale betting system to life planning. Certainly not for everyone, and seeking out such a state is ill advised. I view it more as a way to cope with a situation one finds themself already in the midst of.
Despite this, a person still needs to have hopes and desires, just like everyone else - even if such things are in direct conflict with any hardcore apathy they may harbor.
Truly believing in what you're trying to achieve, as well as the world of possibilities that it will open to you, is essential - even if it does represent a sort of cognitive dissonance. At the same time, you have to not care about the outcome. The ability to have simultaneous belief in conflicting points of view is an incredible tool to have.
To quote an old trading maxim: "You can't win if you have to."
It is something that you can noodle around on (like a guitar, or an electric bass, or even on a midi keyboard software) .. go to a pawn shop and grab an old instrument (put on new strings if necessary) and just play a little every day.
Music helps relieve stress, lets your mind relax, brings you to a creative space, and in a few months of noodling every day or every other day you'll find that your experience of music will have changed and that you'll be making beautiful sounds. Very gratifying, very healthy, and very easy. The juggler must learn to use both hands, the artist both eyes, and the entrepreneur both brains.
Exercise helps, but I'd reinforce the need for a balanced supportive social network outside that. Choose sports with other participants (eg racquet sports, or join a team). Not only will the discipline of not letting others down keep you motiviated to keep going, but you'll get friends who don't give a damn about your business (in a good way - no need to pretend to be killing it all the time!) and can keep you grounded in normal reality.
If you find success early, whether you believe it or not, put some money away (if you can). And if you find yourself in your middling years and great success eludes you despite your prior success, at least think seriously about moving the needle from the risk side to the responsibility side.
Source: I didn't heed this advice.
Your strategy won't work for everyone, or even most people, because "just do it", whilst very compelling short term, tends to lose effectiveness over time. Instead seek out something that you really enjoy, that coincidentally provides great exercise, removing any problem about motivation and long term commitment. If hanging at the gymn really is your thing that's great, but if not, don't beat yourself up, get into something else instead, cycling, karate, trapeze, dance, roller-derby, yoga, there are lots of alternatives, main thing is to make it fun then you won't need the "I must do this" self-discipline every day, you'll go out of your way to do it.
And as others say, explore creative and cultural activities too. Your mind does not thrive on pure coding and hustling alone, it needs its own free-form exercise too.
While not dead certain I may have just found a woman who wanted to marry me in 1985, but her grandmother did not approve of me.
I miss her so. Im going to write her soon, if its her I will go visit but now she is far too old to bear my child.
Several times I have been kissed by beautiful women who made it plain they were mine for the asking but each time I pursued the impossible dream.
My ex did not want to have children. I know why but cannot tell you. Deciding to be with her was one of the most difficult decisions of my life. Now i feel I chose wrong.
Hey Anne whatever happened to Cheryl, she was one of our vendors back in the day.
She died of some very rare cancer. I am completely convinced thats because I did not kiss her back. Not that I was not interested but that i was painfully shy then.
He who hesitates does not get To swim in the gene pool.
Ive written lots of code ive made lots of money. nsome of my products were huge hits.
Consider homer's illiad and odyssey. what code that any of us write will last that long.
There are 3 things that I practice and I feel has guaranteed wins.
1. Fitness-Damn Right. Several people have given the reason. and its as simple as putting half and hour, 5 days a week in moving your body. Keeps you physically fit and mentally robust. At times I have realized that my mental activeness is directly proportion to the exercise and my fitness level.
2. Family and Friends-Yes, they are the support mechanism. Talking to them and taking some time out to talk to one of your closest friends(friend/mom/wife) will help you shift your focus from your business into people that matter to you. Believe it or not at some point you will realize that relationships and people matter the most and investing in them is a worthwhile guaranteed win.
3. Fun-The part would be just having fun, doing something that you love. The best part is you can easily fit it into your daily schedules. Just after your office hours, give 30 minutes unwinding yourself by doing a hobby that you love (e.g. reading a book, writing the journal, playing that guitar, singing songs, playing basketball). Life is short and ultimately everyone makes money so that they could have fun or do what they love, why not do it everyday. It helps you completely detach yourself from your day at office. Fun everyday, keeps stress away.
I'm 100% AGAINST doing it for a "guaranteed win" :-)
First of all, there may be a direct relationship between effort and win when you're an unfit twenty-something, but if you get an injury - or just if your body gets older - you may be struggling to get back to the level you've been at before.
But, even more importantly, if you do sports with a "I have to win"-attitude, you'll start comparing yourself to others, and you'll always find someone who is better than you. Just don't start to be competitive. You're doing the sports for fun. Learn to enjoy sports for it's own sake, and you may be able to take that attitude towards other things in life.
(I've got a failed startup behind me, and one of the things that kept me sane was regularly going bouldering. Pro-Tip: Get a yearly membership as a birthday or xmas present from your parents or so. Even if you're in serious financial troubles, your membership will be paid for. Huge relief!)
This is the magic pill we've all been looking for, and it's been in front of our eyes this whole time. Exercise and a good diet were the answer all along.
You need a lot of these little victories to have a successful business. But that doesn't stop them from being victories. And when you set your scale small enough, some of them are basically guaranteed.
One thing I learnt the hard way is that the best way to ensure personal success is to plan your life's goals as if you have a 9-5 job with secure income. Major investments (housing, loans etc) and relationships should not be on hold till the next company milestone. Having a spouse kind of forces this upon you, but getting a supportive parent/mentor to help you plan your life apart from your startup will really help.
A friend once told me that a guaranteed win for them was cleaning their apartment.
For me, exercise is a good one. Also reading. Reading great books on a regular basis is a life goal for me, and if I just put in the time on that one I make progress.
Sport releases a lot of endorphins that simulate the state of happiness and reduce stress. This is a proven scientific fact. So there's something magic for your self-steem and positivity in it. Everybody starting-up should keep an exercise routine, and startup accelerators should include it in their activities...
It really helps, if you don't have kids like me, I think it's one of the best decisions you can make for keeping your sanity during difficult times. ZEN Meditation and Yoga (mixes both meditation and sport) are other great ways to keep stress at bay.
Just like exercise, the positive effects of meditation compound by putting in the time!
So as an alternative, I'd suggest: Move every day. This can be:
- putting up a basketball hoop and throwing a few hoops
- walking for 45-60min.
- go climb with your significant other
- play with your children (no consoles, actual physical moving)
- do a yoga class
All of these things might not sound like fitness but give you a great balance, when done every day.
>Sleep well, eat well and get fit. 100% guaranteed wins.
>Also, stop smoking/drinking. Hard battles, guaranteed wins.
Also, stop smoking/drinking. Hard battles, guaranteed wins.
That may sound trite, but it's the same for everything. In theory, it's the same as practice. In practice, it isn't.
personally, I've used that site to browse through books before buying them online. In my case, it is beneficial for the publisher to have their books on that site, but I'd imagine most people don't use it that way.
An acquaintance got email informing him hed received an inheritance. Smart guy but not wise to the ways of the Internet. Fell for it hook line and sinker.
You could try contacting them but: not worth the hassle
Let me set the stage.
I'm working with 100+ other developers and probably 300+ total people on this one project. We're subdivided into 20 scrum teams of ~5 developers each.
So far so good.
The problem is that I'm working for a non-tech Fortune 25 company. The person who signs our checks and justified this project is literally six levels of management above me and reports directly to the CEO. To quantify progress and justify the cost (hundreds of millions of dollars) our project is treated as its own organization which has to satisfy a service-level agreement (SLA). This SLA contains completely arbitrary metrics like velocity, defect count, and myriad other things which are only tangentially related to software quality and execution.
This has resulted in the most ridiculous management strategy wherein everything is locally optimized rather than globally optimized. Here are some examples:
1. At the end of every three week sprint, there's a rush to complete stories because if anything is moved, management looks bad. Software engineering standards go out the window because there's literally not enough hours in the day, and nobody is willing to work overtime just to make some manager look better.
2. Speaking of poor software engineering standards, there's so much pressure to close defects immediately that the standard practice is to hotfix/patch everything rather than solve underlying issues. This has created enormous amounts of technical debt in our code base, making working on anything you haven't touched nearly impossible.
3. We're subjected to completely arbitrary pressure any time we're missing the metrics in our SLA. We're not in production or even close to it, and yet our management has had the gall to force six day work weeks across the entire project so the defect count could be brought down. Our strategy? More hotfixing/patching and pushing defects off to other teams, because when you're giving up your Saturday based on some completely imagined emergency, there isn't much incentive to do things the right way.
The end result? Extremely brittle software which satisfies acceptance criteria and has a pretty veneer, but will break the moment you sneeze on it. 200 million dollars well spent.
2. Open an editor and start doing it.
3. Break it up into small chunks so you can feel like you're making progress.
Also, pick something better than a job board. (Unless you're really sure that's what you want to do.) There already are too many people trying to make a better job website.
One thing that helped me, surprisingly, was having a couple of side projects. That made it easier for me to switch around when I got bored with one.
The most important things to consider when doing them is to subdividing it into smaller and smaller projects. That way you will feel the progress and that will help you want to prioritize your project. You need to start with a smaller idea than you might think. Really shave it down to barely working.
Thats at least what worked best for me.
Pick an idea that interests you very much and push it until you release it. Resist the temptation to refactor it, just because a new exciting framework has been released.
Also, google search with this exact phrase you posted here. There are tons of blog posts about it out there.
The more you think then less time you have to do smth
I tested out go for a couple months and found it to be a very interesting language , but I still wouldn't build a rest api with it unless that api was very simple. Its a great language for many things, but I can't imagine a lot of people are using it to build larger mvc service based applications and don't see this happening for the foreseeable future.
File the reconsideration request. If that doesn't work, THEN you've got something to complain about.
cleverbridge.com (used by piritform.com)
bitmicro.com(used by many game dev)
but alas those service doesn't available in my country(indonesia) I want to be software devloper like you ;-). Help me out,you see, my submission asking question about viable option to get paid.
Leverage existing software-ranking sites that have stars/reviews, try to scrape them (or use an API if they offer it), quantify that data and put it into a nice webpage.
You will learn:
- APIs/Scraping- Data Analysis- Some HTML/CSS/JS
It'll be better than starting a project like this, where you "wait for them to come".
1. Webapps (frontends only): circleci, the-guardian
2. Webapps: ghost, gitlab, discourse, reddit, taiga
3. Desktop: blender, atom
4. Mobile: -nothing-
5. Games: O A.D, Hedgewars
And here's the link to the details: https://github.com/jwaterfaucett/awesome-foss-apps/blob/mast...
In our use case, we've mostly had to deal with handwritten text and that's where none of them really did well. Your next best bet would be to use HoG(Histogram of oriented gradients) along with SVMs. OpenCV has really good implementations of both.
Even then, we've had to write extra heuristics to disambiguate between 2 and z and s and 5 etc. That was too much work and a lot of if-else. We're currently putting in our efforts on CNNs(Convolutional Neural Networks). As a start, you can look at Torch or Caffe.
And for comparison, an OCR application with Tesseract inside: It has a dramatically lower text recognition rate: http://blog.a9t9.com/p/free-ocr-windows.html
(Disclaimer: both links are my little open-source side projects)
When I compared Tesseract to Abbyy, the difference was night and day. Abbyy straight out of the box got me 80%-90% accuracy of my text. Tesseract got around 75% at best with several layers deep of image pre-processing.
I know you said open source, and just wanted to say, I went down that path too and discovered in my case, proprietary software really was worth the price.
I have a hobby project where I scrape instagram photos, and I actually only want to end up with photos with actual people in them. There are a lot of images being posted with motivational texts etc that I want to automatically filter out.
So far I've already built a binary that scans images and spits out the dominant color percentage, if 1 color is over a certain percentage (so black background white text for example), I can be pretty sure it's not something I want to keep.
I've also tried OpenCV with facial recognition but I had a lot of false positives with faces being recognized in text and random looking objects, and I've tried out 4 of the haarcascades, all with different, but not 'perfect' end results.
OCR was my next step to check out, maybe I can combine all the steps to get something nice. I was getting weird texts back from images with no text, so the pre-processing hints in this thread are gold and I can't wait to check those out.
This thread is giving me so much ideas and actual names of algorithms to check out, I love it. But I would really appreciate it if anyone else has more thoughts about how to filter out images that do not contain people :-)
If you want to do text extraction, look at things like Stroke Width Transform to extract regions of text before passing them to Tesseract.
It's pretty sad considering that OCR is basically a solved problem. We have neural nets that are capable of extracting entities in images and bigdata systems that can play jeopardy. But no one has used that tech for OCR and put it out there.
As you mentioned ocrad.js I assume you search for something in js/nodejs. Many others already recommended tesseract and OpenCV. We have built a library around tesseract for character recognition and OpenCV (and other libraries) for preprocessing, all for node.js/io.js: https://github.com/creatale/node-dv
If you have to recognize forms or other structured images, we also created a higher-level library: https://github.com/creatale/node-fv
Our particular application was OCRing brick and mortar store receipts directly from emulated printer feeds (imagine printing straight to PDF). We found that Tesseract had too many built-in goodies for image scanning, like warped characters, lighting and shadow defects, and photographic artifacts. When applied directly to presumably 1 to 1 character recognition, it failed miserably.
We found that building our own software to recognize the characters on a 1 to 1 basis produced much better results. See: http://stackoverflow.com/questions/9413216/simple-digit-reco...
With the caveat that none of the stuff was handwritten.
 http://godoc.org/gopkg.in/GeertJohan/go.tesseract.v1 https://bitbucket.org/zaphar/goin/
Examples here: http://funkybee.narod.ru/
Apologies, I am not sure if its open source.
Unfortunately the native Linux version is a bit pricey:http://www.ocr4linux.com/en:pricing
Otherwise I would use the command line version to help me index all my data.
Also, since moving into our current building they've added sound-resistant walls and barriers in various places which has helped significantly.
(Speaking for myself, as a happy employee.)
there were no windows, and so many computers that it was very noisy and hot.
Now when i interview i ask to be shown where i would sit.
Do you actually enjoy your current job?
I find that if you don't really enjoy what you're doing, you end up living in this perpetual state of stress. And while that stress might be small at any one given time (minor annoyances here and there), because you're working for 8+ hours/day, it really adds up. Bodies aren't meant to be chronically subjected to cortisol (stress hormone).
I hate my current job, and I completely 100% empathize with the way you feel. I shifted my sleeping schedule so I could get 2-3 hours of work in before leaving for the day, but I just feel so beat down that I can't motivate myself to do anything.
I'm getting ready to leave so I decided to take the rest of my vacation time to prep for interviews. The difference is night and day - I've been studying 10+ hours/day without slowing down and I finally feel like I'm full of energy and hope again.
Maybe you just need a change of scenery.
I went to a book signing by Brandon Sanderson. Not a huge fan of him as a person, but he's a fantastic writer and an incredibly smart man. He started off the signing with a little story about creativity. When Brandon was in college, he worked 3rd shift at a hotel. He'd go to school in the mornings, sleep in the afternoons, and work all night. He tried to roll his own degree, but they made him stick to the Creative Writing plan. Instead, he decided to mix up his electives -- take as many subjects as he possibly could. A writer needs to know about history, science, philosophy, technology, and so on. You can't just spend all day in English classes and expect to be a well-rounded writer!
So he took as many classes as he could. He'd go to class in the morning, sleep in the afternoon, and then get to work around midnight. In between checking in guests at the hotel, he'd work on his homework, and once his homework was done, he'd write for hours. He wrote his first six or seven novels while working at the hotel (the last one was actually picked up by a publisher or publication).
He said that he had no problem with this schedule... except for his programming class. He was taking a class that used Pascal, and he'd get to work, do his Pascal homework, and then be completely unable to write. He took dozens of classes at university, but the only one that left him completely creatively drained was programming.
In other words, programming took just as much energy out of him as writing did -- it exercises the same brain muscles, so to speak.
I don't really have much of a point to this, other than to say that a rather well-known fantasy author commiserates. Programming is hard. It's draining. It's being non-stop creative in solving problems.
My personal philosophy is this: everything can wait until tomorrow. When the clock hits 5 o'clock, start wrapping up. Find a stopping place, and pick it up tomorrow. Barring servers crashing, the work will still be there tomorrow. I don't check my email, I don't open my laptop, I don't do anything work-related once I get home. Home is me time. Nine-to-five is company time.
I guess there are two things here: programming is hard work, and draw a line between your personal and work life.
Standing desks help some people as well but not nearly as much as the former combined.
1) get your thyroid levels checked.
2) sleep apnea.
3) possibly anemia
After that advice is around sleep hygiene, then food and exercise, and stress resiliance
Typically I write code in chunks of time not exceeding two hours, after which I shift to other tasks: catching up on emails; writing specs or drawing diagrams; thinking about larger-picture issues; reading work-related documents or instructional material; talking or IMing with coworkers.
Also, I take walks, go swimming, go for a run, go to the gym, do some pushups, get a coffee, read a book, play a musical instrument in between programming sessions.
Those context shifts make each programming block more meaningful and concentrated for me.
My most productive days usually leave me energized, not exhausted.
I think most people are not equipped to deal with monotony/drudgery. I find that it really helps to have hobbies that will recharge you mentally. Double plus if that hobby happens to involve physical exercise. Eg: I'm trying to develop swimming and squash as hobbies. There will be days when I'll be be listless and frustrated, but a couple of hours of these mentally relaxes me enormously. Also, I often prefer more active to passive forms of relaxation, like playing pool/carrom by myself. HTH; Good luck!
Other responses on this thread have good suggestions (friends, etc. Spending time with your partner, or dating might also help). Loneliness is often a trigger for listlessness. Needless to say, get your health checked and ensure you're having a healthy diet.
This sounds like the work you do in those 8 hours is either:
1. Not challenging enough or
2. Too much for one guy (you) to handle.
You're zoned out. Figure out which one it is. There are meditation techniques to give your mind the space and time to think about this. A simple break (a week or more) away from the work is often good enough for me while my mind subconsciously processes things. (Don't do any work during this break!)
If you find that the work is not challenging enough, change your environment, move slowly into more and more challenging work where you feel the feedback of accomplishment re-energises you. If this move is based on a request to a boss, client etc and it falls on deaf ears, start looking for another job/client.
If the work is too challenging, ask for sensible deadlines (fuk I hate deadlines!), scope reductions and a kinder work environment. If this request of yours falls on deaf ears, start making plans to quit for an alternative that is better.
The fact that you picked this up is already a good sign.
When doing so, walk around a bit. It is important to physically separate yourself from the work area. I recommend going outside and taking your mind off of whatever task(s) you are immersed in solving. Doing so with a coworker you get along with often adds to the benefit.
I set a phone timer for 18 minutes, lay down in the dark, and nap for a bit. 18 minutes is completely arbitrary, but my body has adjusted to that time specifically, for me.
Also if you go wide open for any long period with no down time you are going to burn out and start thrashing. 2 weeks is my limit.
Intention is important. If I start the day with the intent of having something left over for myself at the end it really helps.
2) eat breakfast before work
3) get out of the office for lunch, maybe even have a beer with friends, once in a while
4) stand up for yourself while at work -- challenge silly tasks and try to delegate 'crap' work
5) get a medical checkup
It helps you to relearn to relax your parasympathetic nervous system, which might get 'jammed' in the day being stuck at a desk for 6+ hours.
Also, if you want to sell software directly to customers, Skrill can work here too.
Beyond that, you need to start working on long term solutions. I don't know what that would be in your case. Maybe you were asking for a viable solution to run an online business? I am not 100% clear here.
I wish I could send you money. I can't. I am homeless myself, though homeless in America. I struggle to get enough to eat every month. So I don't have money to spare.
I am sorry for some of the replies you have gotten here. There is no shortage of callous jerks in the world who just don't appreciate how good they have it.
You could set up a UK company, for example, and accept payments through Stripe and Paypal in name of the company. The company can then pay you a salary/dividends/etc.
Religion is a choice, not a race. Nobody is "born Christian". You're born naked and crying with no such concept.
Religious intolerance can sometimes be aligned with racial intolerance, but it isn't racism.
maybe a indonesian processor, like doku?
best to get a real job for day and sell software as a side job. maybe something where you can get tips from tourists like taxi driver, tourguide, bar tender, resturant server (not sure if they tip there), or something like that.
Skills that you can offer?