pcowans
pcowans on Hacker News
Try to sit in the middle of the carriage. I don't get motion sickness on trains, but I find doing that makes a meaningful difference to how comfortable it is to type on a laptop on a commuter train.
Develop a sense of curiosity, get into the habit of asking yourself why things are they way they are, even if you don't need to know the answer. Read widely about technology and follow the threads to new topics. Try things just to see how/if they work. Go's a great start - it'll get you thinking about programming language design, concurrency, networking, etc., and all of those will lead to something else.
You'll also need to be comfortable thinking about things you don't understand. If everything you do is familiar to you you're not thinking broadly enough.
Yes, I've experienced this exact problem in the past.
From the article: "To be clear, Malik isn’t talking about Kickstarter where funders make a donation that acts like a pre-order. He’s talking about the public buying stock in private companies, something that may soon be legal thanks to the JOBS Act..."
I think the total energy available at ground level is something closer to 250W/m^2.
It's even called stereolithography :-)
... one other thing though. With a bit of practice you can remove the need to develop on feature branches; break things down into really small chunks and get into the habit of making half-done features unobtrusive (e.g. hiding UI elements until they're ready). That way you can push to master often and have confidence it'll always be safe to deploy, which simplifies your tooling and reduces the scope for merge conflicts etc.
Don't worry about it then - there are more important things to spend your time doing.
This doesn't seem that bad to me, what problems is it causing?
The only changes I'd make would be to wrap it up in a script so you have one-click deploys, and possibly implement the 'copy and symlink' strategy that Capistrano uses so you have minimal downtime during deploys and instant roll-backs if necessary.
That should never be necessary; if you invest in the appropriate automation you can get your regular deployment process down to a few minutes and then even emergency fixes can go through the normal channels. The benefit is of course mainly the ease of day to day deployment, but it does mean that in those emergency cases you don't need to worry about what you've forgotten to do, or how your changes might mess up the assumptions baked into the automated system.
So, obvious question... why do you not have tests in this set up?
This is true, but you should probably still put more emphasis on avoiding them than optimising your process for fixing them.
YouTrack (
http://www.jetbrains.com/youtrack/index.jsp) is my favourite out of everything I've ever seriously used. Physical cards stuck to the wall also works well for small, co-located teams.
The important things are that someone needs to put a decent amount of time into managing the bug list, and you need to be actually willing to devote appropriate resources to fixing them (or better still, eliminating the root causes). If those aren't present you'll just end up with an unmanageable dumping ground regardless of where it lives.
Okay, cool - so it seems like you do actually have quite a specific piece of technology missing, but it also seems to me that this is an architecture / technical design problem rather than just needing someone to code it up. It also seems that it's pretty core to what you're trying to do, which to me suggests that you really need a find a way for yourself or someone with a long terms stake in the project to own this piece.
If you were able to encapsulate that part of you product (the simulation and associated data store), would you feel comfortable architecting the rest of the system (whatever that is - web interface, associated company website, etc.) and bringing someone else on board as a contractor using fairly standard technology (e.g. Rails / Django)? If you could do that it'd free you up to focus on learning the bits which really matter.
Putting my two cents in technically, the way you're describing this makes me think that it's not necessarily a good fit for a traditional RDBMS - 'hundreds' of tables of fields strikes me as an unconventional way to use these technologies, but I don't know enough about the problem you're solving to suggest what might be more appropriate.
So what is your background? It seems like you have experience doing something technical, even if it isn't professional software engineering. Do you feel you could code up a workable implementation of your network simulation in Python which could be encapsulated as a component of a larger system using a mix of technologies? Separating things out into modules for which you can (in theory) implement using different stacks is generally a good idea in any case.
Can you say more about how your product is medium computational intensity? i.e. what makes it more complex than your average databased backed web app? Why do you feel that code quality is more important for you than for an average project?
The architecture of your application is more than a one-off decision about tech stacks made at the start, and I'd say that you really do need someone with a long term stake in the company who's able to own this on an ongoing basis. I don't know whether there might be ways to get an advisor on board to do this rather than making a full hire.
> 1 - what do you think about users paying in advance?
I guess it depends on your attitude to risk and the sort of service you think people will pay for. If you don't you presumably need more working capital, which has a cost, and you're taking on the risk that people won't pay but you're stuck with the goods. You're basically getting into traditional retail.
> 2 - what do you thin about the 5%?
I wouldn't pay it, but I don't have a problem paying for things online. You need to figure out what your target market will pay.
> 3 - do you think the buisness model is broken in anway?
It sounds like something which will need careful risk management, and may require a lot of capital. (Edit: Basically this isn't anything new - you're proposing becoming a retailer of 'stuff from ebay' as far as I can tell.)
Exact duplicate rows? If you have access to standard Unix tools, try this on a command line:
cat input_file.csv | sort | uniq > output_file.csv
Can you be more specific about how large 'large' is?
Edit: without knowing the specifics, you might like to look at Elasticsearch (http://www.elasticsearch.org/). That'll give you an HTTP/JSON API into your data, so you might be able to do all the UI work you need client side, e.g. with Backbone.js (http://backbonejs.org/) or similar.
You can be pretty sure that it is. You should definitely do competitor research, but also don't reject ideas just because someone's already doing something similar. Execution is much more important, and the details do matter.
In the case of phones maybe it's the fact that you've just been holding it against your body for a few minutes.
This may be the difference between being a contractor and being after a permanent position. For the latter, with the exception of very senior roles, you don't often hear people talk about them as anything better than a necessary evil.
So, at least we've got from 'I'm too gifted to learn from anyone' to 'I'm in a difficult position without access to peers to learn from', which sounds more plausible and is probably worth sticking with.
I guess you have two options really - find another job that will give you access to a team, or start doing something to give you contact with programmers outside of work, whether that's getting involved with an open source project, finding a meet-up to go to, taking a class, etc. In any case, approaching it with an appropriate level of humility is probably a good idea.
... and finally, teaching yourself C++ from a book isn't exactly unusual. I'm entirely self taught, and I'm sure a lot of other people here are too.
... having said that, on a good team there will be a culture of code review. Have you ever asked for feedback on your code?
Yeah - that's life, the people who will tell you what to do next are few and far between, and you need to demonstrate that you deeply care about them (possibly in ways you don't yet understand) before they'll reciprocate the favour.
And am I confused here? I'm interpreting std as the namespace in which most of the C++ Standard Template Library lives. I assumed you were using them synonymously, because I've never heard anyone refer to std as anything more than a symbol used in STL code. Maybe there's a different acronym I'm not aware of though.
Although I kind of agree with you that iterators for vectors aren't really very necessary, for std::list, std::map, etc. I think they're quite a sensible way of sequentially accessing the data - you'd pretty much have to re-implement them if they didn't exist. In the case of maps, I don't actually think the container implementation is specified enough to allow you to get away with any less abstraction - it technically doesn't have to be a BST, although I guess you could argue that the containers should have mapped to precisely defined data structures in the first place.
C++11's type inference does make STL iterators a lot less ugly, by the way. Also (referring to the initial post), there's no reason you have to use for rather than while when using iterators (while(v != c.end()) ...).
Stop defining success in terms of praise from others. At best you'll spend your time doing unfulfilling work and not learning much, and at worst you'll be manipulated.
From the discussion in this thread I don't believe that you're a particularly effective developer - it seems you're used to playing the hero programmer role and have been too poorly managed for anyone to question that. Your descriptions of the C++ STL show that you don't know what you don't know, and if I were working with you I'd be asking all sorts of questions about what was going to jump out of your code and bite us further down the line.
You're probably smart and have a lot of potential, you just need to realise that there is a vast amount that you don't know.