It feels like a very minor upgrade.
The only thing that seems improved is that transparency mode seems closer to true “transparency” but it’s a relatively subtle improvement.
45 karma · joined October 4, 2010
The only thing that seems improved is that transparency mode seems closer to true “transparency” but it’s a relatively subtle improvement.
(I’d probably wait for more usage and supporting evidence before trying something like this, but the prospect of no-regrets dairy consumption is very appealing.)
I’ve seen Platform Engineering take various different forms, but it’s current incarnation is split into 2 teams:
1. Developer Productivity. Ownership of quality, efficiency, and developer tools. A recent example project was improving the quality of our test data capabilities to make manual testing easier/more consistent.
2. Unified Client Platform. This team owns our design system and is the primary owner of our effort to unify on React.js/React Native, though a lot of the heavy lifting is distributed around the team.
(I mostly wanted to weigh in since at a mid-sized company at least, we’re not interested in building our own PaaS… k8s or Lambda is fine for that. Instead, we want to ensure developer onboarding is painless and anything specific to us is easily understood - the bulk of the surface area should be best-in-class 3rd party tools or ideally popular OSS frameworks.)
Connection setup/tear-down is cheap in MySQL but expensive in Postgres.
- uwsgi - Python - Django - Docker - k8s
Then the bits and pieces outside of the Python stack itself -
- MySQL and Postgres - memcached - redis - RabbitMQ
We believe that everyone should be able to experience the unconditional love of a dog. That’s why Rover’s innovative platform makes it easy for pet owners to connect with 5-star pet sitters and dog walkers across the U.S.
We've raised $150mm+ ($200mm+ if you include DogVacay, which we merged with this year) and the business is growing quickly. We want to grow our engineering team by 30 or 40 engineers over the next year or two to support our ambitions of becoming the one-stop-shop for everything dog related.
Our backend is predominantly Django and we're looking for engineers across the board, but our primary focus is people with significant Python experience in a web context. (Flask/Pyramid/whatever experience is great!)
You can check out our specific postings at https://www.rover.com/careers/ or shoot me an email at (my-first-name)@rover.com if you have questions or want to learn more.
We believe that everyone should be able to experience the unconditional love of a dog. That’s why Rover’s innovative platform makes it easy for pet owners to connect with 5-star pet sitters and dog walkers across the U.S.
We've raised $150mm+ ($200mm+ if you include DogVacay, which we merged with this year) and the business is growing quickly. We want to grow our engineering team by 30 or 40 engineers over the next year or two to support our ambitions of becoming the one-stop-shop for everything dog related.
Our backend is predominantly Django and we're looking for engineers across the board, but our primary focus is people with significant Python experience in a web context. (Flask/Pyramid/whatever experience is great!)
You can check out our specific postings at https://www.rover.com/jobs/ or shoot me an email at (my-first-name)@rover.com if you have questions or want to learn more.
Are you collapsing your migrations?
Unless you need to maintain multiple production environments with different versions of your software you should be doing so with some regularity.
Rover.com - SEATTLE
Let's make a checklist...
1. You love dogs. Check, we got that => https://www.rover.com/rovercam/
2. You want in on the collaborative consumption marketplace trend. Check, we got that.
3. You think dog boarding is a niche market (but actually the market is bigger than all of online advertising!) Uh-huh, check.
4. You want all the stuff a good startup has -- modern dev practices, lots of autonomy, great team, lots of funding, etc. Check, go that too.
Yeah, we got all that stuff. Check it out: http://jobs.rover.com.
# ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ # ~ #
_
,:'/ _..._
// ( `""-.._.'
\| / 6\___
| 6 4
| /
\_ .--'
(_'---'`)
/ `'---`()
,' |
, .'` |
)\ _.-' ;
/ | .'` _ /
/` / .' '. , |
/ / / \ ; | |
| \ | | .| | |
\ `"| /.-' | | |
'-..-\ _.;.._ | |.;-.
\ <`.._ )) | .;-. ))
(__. ` ))-' \_ ))'
`'--"` jgs `"""`
"We don’t have billion dollar Internet companies with the likes of Microsoft, Google, Facebook, and Amazon."
With a discussion only of Silicon Valley, given 2 of 4 are based in Seattle.
One of my co-workers used to pound on PGSql pretty hard in a very high traffic environment and has nothing but good things to say, but I'm not crazy about the idea of having to learn all of PGSql's foibles like we have MySQL.
My impression is that MySQL 5.6.x (we're on 5.5.x) should help with the schema migration pain, but I don't have any hard evidence for that claim.
My hope is that MYSQL 5.6.x will remove a lot of the pain, but I don't have a
(It may well just be my environment, but it is fairly standard RDS on AWS.)
I used to inline the CSS as more of a onetime build-step type thing, but found it to be a real pain.
The main downside to this approach is rendering is quite slow, but emails should probably be fired off in a task queue anyway, so meh.
I'll bet one natural result of it entering core will be better shared understanding of best practices & foibles of different backends.
Managing migrations on increasingly large tables is stressful for me primarily due to my lack of knowledge, moreso than fragility in any piece of the puzzle.
In any case, I've thrown in my pledge - best of luck!
(If anyone has any good recommended reading for DBA-type knowledge in a devops world, I'd love an Amazon link you think is worthwhile.)
Low cost of living, really cool neighborhoods and lots of smart programmers at stodgy big companies. It seems like the city just needs some capital & a few experienced tech entrepreneurs to get it going.
That being said, I don't know of any Wash U CS grads that stayed in St Louis for startups - they all headed for the coasts (me included.) Hopefully that'll change over time.
If you love dogs and want to talk about software (We're all on a Django stack) send us a quick introduction to tech-jobs@rover.com.
That's exactly what we want to facilitate. Tons of people would be willing to watch your dog overnight, but there's no easy way for them to do so.
We're in Seattle for now, but have every intention of expanding in the future.
I once was in a class where an ITC commissioner (or something like that) came and talked about the ITC's role in international trade.
My limited understanding is that they typically are somewhat of a domestic alternative/pre-cursor to WTO type disputes. For example, the two cases I heard about were both antidumping cases: one about chicken products and one about bedroom furniture.
How's that for a random and mostly irrelevant contribution?
I don't know whether this will be the eventual solution vs. ZenCoder (or something similar) and S3, but this certainly seems like a potential option.
Supposedly there's a concept of "non-obviousness" but every patent that is disputed is strikingly obvious to a "person of ordinary skill in the art."
On a panel of 5 competent engineers, asked "How might we go about identifying potential credit card fraud on the Internet?" I suspect all 5 would independently bring up the idea of storing customer IPs and comparing that to IPs that have used that credit card in the past.
I can't help but feel like patent law is just a way for lawyers to extract money from people actually trying to make things.
I personally prefer Django for a number of reasons though I've also been impressed by RoR in my dabbling. active record's migrations are nice, and the ease with which rails let's you write dynamically changing forms and various other niceness is really great.
Technical questions aside, I think RoR is the default web framework. At general hacker type meet-ups like Startup Weekend, Rails is pretty much the default framework to work in as more people are familiar with it.
Django is wonderfully well structured and literally just about anything can be accomplished elegantly by subclassing this or that. As you said, the difficulty comes in figuring out what and how to fill in those gaps, which more often than not includes heavy use of grep and browsing around the Django source.
I think you'll be fine with whichever you choose. Learning new languages and frameworks is enjoyable, so try some rails and see how you like it. Smart people and great projects have been done with both.
Presumably Groupon has actual plans for becoming profitable, but big IPOs of companies with dubious fundamentals does sound like a description of a bubble to me. (Linkedin's stock was briefly over $100 - crazy!)
I'd really like those libraries to work on OSX, Linux & Windows, but so far it has been easier to just install those two packages on the machines I need them on.