In the example situation the choice wasn't quite so clear, as IP was on the line too.
Regardless:
A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.
376 karma · joined June 5, 2012
Regardless:
A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.
I do think there's a disconnect between which pieces of data people think are public vs. what is actually public. My git commit email was one of them. That's what I'm trying to illustrate in my post.
Read the top comment, then scroll waaay down to the bottom.
Full disclosure: I work for Shopify
This is great, and I'd much prefer to simply star projects and have them appear than use a bookmarklet if possible.
overall, I feel that making every little button wiggle when I mouse over it would be distracting rather than helpful. I can't see myself using these.
Shopify is looking to grow the team responsible for building the future of Shopify. We’re in search of back-end developers with a passion for solving hard problems with performant code. If you are interested in creating great products, building new features and improving the existing Shopify features, then please apply!
Developing Shopify
Shopify is the longest continuously developed Rails app on the planet and we care a great deal about code quality. Shopify, in contrast to most other rails shops, always runs on the latest rails version. Many core rails features have been developed within Shopify and have later been added to the Rails framework. We often go back and improve core parts of the Shopify codebase to make it better or more lean. We can do this because we have a positively massive unit test coverage which will immediately sound the alarm when something goes wrong.
We ship on quality instead of on time. When a feature is ready we deploy it immediately to everyone or use an internal system to roll it out to a certain percentage of customers. Various teams deploy new code many times throughout the day.
Shopify's production scale is massive. We host tens of thousands of online stores and regularly see hundreds of millions of requests a day. When you push out new code tons of people will see what you made within seconds. Operating on this level is hard but incredibly rewarding.
Responsibilities:
* Write back-end code in Ruby and Go.
* Work with a world class design and product team.
* Providing beautiful and fast code that improves the code-base of our products in meaningful ways.
* Use TDD to write rock-solid code, utilizing our huge test suite to make changes with confidence.
* Rapidly fix bugs or take your time to solve hard problems well.
* Deploy code to hundreds of servers and tens of thousands of customers in your first week.
* Never stop learning. Shopify is an environment of constant personal growth.
Qualifications and Desired Skills:
* Know Rails or be ready to learn it quickly.
* Proficiency with UNIX commands.
* Knowledge of relational databases and SQL, we use MySQL.
* Strong commitment to quality.
* Experience building and scaling user-focused web application.
* Being awesome and having a love for Shopify - Major Plus!
Seems to me that VSRE/VSRO telegraphs what should be known anyway. I don't like it.
I'm somewhat ambivalent about it though. On the one hand I find it easier to read (less scanning back and forth across the page) but on the other it is forgiving to deeply nested code.
That's why we want people to submit third-party widgets and jobs. We can't cater to all environments ourselves, but others can help out and share their own.
The current implementation requires you to send an array of hashes with the x and y co-ordinates you want to plot.
Here's the example job where you can see it in action: https://github.com/Shopify/dashing/blob/master/templates/pro...
The thinking was that displaying exactly the same data on a TV, desktop, and mobile device isn't ideal. The dashboard is designed specifically for the display. If a mobile version is needed, then the relevant widgets can easily be put into a new, mobile-optimized dashboard.
The same could be achieved with carefully designed media queries, but I feel that separate dashboards do the job better.
The real meat of the project is the underlying messaging that passes your data from the server to multiple clients.
You write a job that calls send_data, and Dashing takes care of the rest. There's room for as much customization as you like on the front end.
At its core, Dashing is just a promise that all your data makes it to all your dashboards.
http://en.wikipedia.org/wiki/.in
http://en.wikipedia.org/wiki/.it
CIRA, who manage .ca domains, have stricter rules. They can be found here: http://www.cira.ca/why-ca/ca-101/who-can-register-a-ca/
Many registration authorities choose to let anyone buy their domains because it's a big source of income. Libya is one of those (or always used to be. Since the revolution it's been less clear).
I'm curious though, how high a transaction fee would you pay if you were on a free plan? Most merchants HATE percentage fees and want them gone completely. With that in mind we do our best to minimize them.
Maybe TicTail will be a huge success. My point is that even though they have 10,000 customers we should hold our judgement until they get their business model up and running properly. When the dust settles, we'll have a better idea of how they're doing.
That said, Tictail is currently a free service. From what I can tell, no-one's paid them a penny. The real test will be how many of their merchants stick around once the add-on pricing is (a) announced and (b) goes into effect in May.
EDIT: From their help section (http://help.tictail.com/customer/portal/articles/531368-how-...):
> Our ambition is to offer these add-ons at between 1€ - 5€ / month.
(full disclosure: I'm a Shopify employee.)