No. Coming up with ideas is easy. Coming up with ideas I'll care about in a month & be willing to make sacrifices to have time for often enough to make meaningful progress is what's hard.
121 karma · joined January 10, 2015
Android support is due Soon(TM). It just launched with was ready.
For that matter, $8k+ per week at 50% utilization is still $165k at the same fudge factor for taxes & overhead. That's already well beyond my threshold for "I've increased this variable to the point that further increases are nice but not a primary motivator, and I'd rather that further optimization focus on quality of life as the primary variable."
E.g. frequent community sites like http://inbound.org, check http://meetup.com for relevant events and participate there...
The default is small, but I almost never remember this issue because my browser remembers the zoom setting.
Memcached isn't bad or anything like that. There are many algorithms where "let old stuff fall off the page" is perfectly healthy. I just don't see a need to use both, and I prefer explicitly designed expiry behavior vs. letting stuff fall out of memory, and I find Redis easier to work with.
$0.02, YMMV. If your engineers are used to working with both, having both available costs way less than making them do mental gymnastics to get around not having it, although that might take itself out in onboarding time or code complexity or whatever. But mostly not, if you have good interfaces set up like Patrick.
P.S. - Don't put sessions in Memcached, ever. Having users sessions die randomly because you used too much RAM is terrible design. Putting them in Redis is fine, in which case you probably want to set an expires property when they're created & update it when they're read. Or issue a rename if you're doing one-request-per-key, whichever.
Also, most things that people will tell you re: build portfolio, contribute to open source, etc. — it's largely a waste of your time, at least with regard to getting a paycheck with large numbers in your hands as expeditiously as possible. Please, contribute to open source, I need that stuff. But don't do it because you think you have to in order to land job interviews.
If your skill and discipline as a "get stuff done every day" developer is roughly no better than your average junior web developer, that's approximately a $90k/yr position for which the market has deep unmet demand. The set of people who are hiring decently competent developers is approximately "everyone with an existing software development team."
A much better approach is:
* Make a list of companies you would be interested in working for
* Figure out who at these companies is currently managing a dev team
* Contact those people, convince them you can write compiling code
* Discuss doing work for them in exchange for large amounts of currency
Beyond that, understand that you're going to have a learning curve to get your "getting stuff done every day" and domain-specific development skills up to spec. Right now, you're probably about as productive as a junior developer with six months of industry experience. This sucks, but you're already aware of it. The typical grad student is shit about e.g. coding as part of a team, using commit-driven development, issue tracking, that sort of routine process things that keep work happening regularly - even if they have a great grasp of their chosen languages(s) and tool(s), which many do not.
If you play your cards right, the learning curve from there to "competent if inexperienced senior developer" is about 6 to 18 months for a typical engineering grad student who has some experience mentoring undergrads and helping them through issues like "this wouldn't have happened if you'd just use version control" and "would you please write comments that tell me what the heck you're trying to do with this block of code."
At worst, the outlook is about the same as a run-of-the-mill junior developer, who is still likely taking home an embarrassingly large paycheck while they improve their skills.
Your safety net is "CRUD monkey." That already pays well enough to make the median dual-income American family rather jealous. From there, what do you want your career to be? Application development? Graphics? Data science? Database engineering? Pick something, find teams that are working on that, talk to them about the work they're doing. Bonus points if you already have some understanding about their subject area based on reading you did as a grad student, or projects you worked on, but they likely already hire people with less domain experience than that.
People behave very differently depending on the UX of the communication tool involved. Moving to a tool which reframes the implicit social contract of the conversation can do a lot to relieve problem points.
Email supports large asynchronous messages with no global threading. Which means people are free to shoot off as many as they feel like, as often as they feel like, and each of those drops an anvil on your todo list.
Refactoring that as a chat room with distinct threads only for distinct topics means that you can only talk for so long without realizing that you're tossing a big rambling mess in someone else's lap without digesting it first. It's also an "asynchronous realtime" conversation that you can pick up, step back from as needed (concentrating on code, phone call, support tickets, etc.) and search later if you need to. Seems simple, but very different UX, and tends to be more civilized as a result.
Then use Trello or whatever on the side, for a communal view of persistent tasks & their progress. And email, but only when you actually NEED it, not for every damn intra-office conversation.
Being more restrained about email helps, and is necessary anyway, but you can only get so far with that approach. The tool itself is feeding the problem, and while you can do a lot to train your team to have better email etiquette, it works better in the long run to meet the need with something that doesn't have the same structural issues.
The reason WordPress tends to be root city is that there are a great many installs out there, of which many have never had step one done to harden it, and were last given security updates ~ when they were installed.
I would still outsource WordPress, but that's mostly in the vein of "the cost of outsourcing is less than the cost of me having to think about it one hour a month, while 1 hr/mo is a reasonable floor for the time cost function, but the actual value will probably exceed that at least once in a given year."
A WPEngine subscription costs $30 to "I don't care, why are you wasting my time with numbers this small." Developer time costs between $75/hr and "everything is on fire and you can only put out one fire at a time." Ergo it makes economic sense to configure nginx / DNS once, then outsource further complications to paid external support.
There's also the possibility that BuzzFeed et al. are proportionally overvalued, which seems like it's probably the case in some instances, but the argument you're making if "valuation >> revenue - costs" is that the right hand side of the equation is accelerating in a way that justifies the left hand side.
It's widely used by EE students to help study for exams, figure out labs, etc.
At which point, we're talking about basic customer development interviews, which are way more useful than "google up a list of possible alternatives."
1) Is this actually a concern to the people you want to be selling to, as evidenced by talking to a number of them? Don't bother with surveys, just straight-up have a non-sales conversation about it with 10 people who match your target customer model.
2) Lots of people don't read a ToS. Or if they do, they're not going to be 100% confident that their interpretation is what will stand up. If this is a legitimate concern for your users, you need to allay that concern, directly, in your primary sales contexts. Make it a focus item on your landing page, with design such that people will see it and go "oh, okay, I don't need to have that concern after all."
1. You can charge more.
2. You take on more work in parallel.
The second is usually a thing to some degree, you add devs etc., but it doesn't drastically increase your earnings per head so there tend to be diminishing returns - network costs of a larger team, the need to sustain a flow of more and larger deals. This requires some drastic changes to the company itself, how you work, the type of deals you pursue...it can be profitable, but it's a mess.
Which leaves #1, increasing the value of deals you take on with roughly the existing team. What is stopping you from doubling your next quote? Skills gap? Type of project? I'm betting it's more "type of client" and "sales process" than needing another developer, since (from a once-over of your team section) you seem to have the major bases covered already, and perhaps more so than you'd need with a more narrow project type & target customer.
Re: specific roles you asked about...
There are technical writing specialists & sales engineers. A good sales engineer is expensive if they're any good, and very likely overkill for a small agency. It's usually up to the person or people running the agency to learn sales. There's a spectrum of skill involved, but even the shallow end makes you VERY dangerous in comparison to the median sales-averse developer.
As to a technical writer...how much does documentation affect your deals & billing rate? This can probably be better addressed by process, make improving doc quality a real priority by setting aside time for it every week & comping for training materials on better docs and copywriting.
There might be ramifications, and it's up to you to run through the calculus of whether that means more to you than getting out, but if you want out and you're fine with the results, go for it.
This is something I would wrap a simple CLI around, and then kick myself in the tukhus for having ever used the language's interactive client to make raw database queries and edits on the production server.
This is not a problem where you need precision, just a reasonable level of accuracy and a well-presented argument.
I put code on GitHub on the off chance someone else will find it useful or informative. Between the user base, platform usability, and the fact that I use git anyway, it's convenient for that. But "portfolio" isn't really a consideration.
If, for some reason, you want a portfolio anyway: my recommendation would be private website + GitHub. Preferably, in the form of writing an article demonstrating why a given project on GitHub is novel or interesting or useful. If you go that way, any off-the-shelf blogging tool should work (e.g. Jekyll / Octopress + GitHub Pages), and it will tend to be more useful to the community as large (which increases the odds of other devs explicitly being interested in working with you).
1. Generate a server signing key using urandom(key_length).encode('base-64') and store it in app.config['SECRET_KEY'] via config.py and appropriate .gitignore, or environment variables, whatever toots your horn.
2. You now have a secure signed session cookie, congratulations. This is a "user session data" cookie, i.e. a simple key-value store in the user's cookies accessed from flask via session['key'], so set session['sid'] to some long random .encode('base-64') key that maps to the user via Redis (or your RDB, if you want to only use that).
3. Use Flask's @app.before_request decorator to determine who owns the session ID and store the appropriate user ID in the Flask.g request context.
4. The @app.route gets the user ID from Flask.g, never the session. Any calls it makes that need to know which user are given the internal ID directly (i.e. the user ID in the users table).
A lot of people don't even go to that extent, you can do more or less the same thing via Flask-Login or Flask-KVsession. If you're using either, I'd recommend reading through the project code on GitHub to see what happens as a result of the context decorators. It's not terribly complicated in either case.
So back to the original problem, if you want both services to be able to verify the signing data, you give them the same app.config['SECRET_KEY'] and have them share data about how session keys map to users.
Or you could use an "I am Joe Johnson" cookie schema and forego session keys, if that's appropriate. If so, just put it in session['username'] and let the session sign it. Ta da, done.
If you have to start thinking about encryption strategies in Flask, beyond "use passlib.hash.bcrypt_sha256 on user passwords," you done fucked up already. It has great tools to keep you from ever having to touch that stuff, so please use them.
The above story should be roughly equivalent for Rails, once you change the names around. Node.js, I'm not sure, but there's probably a library for that by now. Use it.