Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shopify POS

shopify.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Shopify POS

#111

Post by HyprMusic »

ericingram wrote: post #87
HyprMusic wrote: post #39

Earlier quoted context omitted.

Agreed. The control they give their theme developers is shamefully woeful. You're actively encouraged to use Javascript as a work-around for their very limited templating sytem. If they were to add querying, or even just a few more options for selecting products (e.g. by type, brand, etc.) then Shopify would be a great contender to other e-commerce stores. Currently it feels they're only focused on things that can br…

I'm the founder of Forward Commerce ( http://getfwd.com ), a new platform focused on giving developers more template control without all the pain. One of our early adopters was a very notable/early Shopify customer who encountered the kind of problems you describe with templates and customization. I am pleased to say they have been successful using Forward and Shopify combined in order to solve these problems, and ar…

Your project looks interesting, I love the fact it's open source with premium hosting - the ideal way to do it if you ask me.

Re: Shopify POS

#112

Post by recurrie »

wheels wrote: post #89
deadlysyntax wrote: post #88

As the director a development agency, we cannot use Shopify for our clients until they create the ability for products to have custom fields. Some products need to present more information than is standard, such as a wine store that needs to display vintage, alcohol. volume etc. Til then this excellent new technology is useless to us.

That's been available for 4 years: http://www.shopify.com/technology/3032322-new-feature-metafi...

Unless I've missed it, there isn't a way to cleanly add meta fields to the admin backend for products. It has to be done via an app, which means data entry needs to be split between built-in Shopify fields and meta fields via a Shopify app interface on a different screen.

Re: Shopify POS

#113

Post by orenmazor »

jacques_chester wrote: post #104
orenmazor wrote: post #22

Earlier quoted context omitted.

I work on the new Shopify Reports product and we would love to hear more about what kind of complex sales reports you're looking for. hit me up here, on twitter (@orenmazor), or email: oren.mazor@shopify.com

Suggestion: provide a dimensionally-modelled reporting schema, it will be much easier to query. Kimball's The Data Warehouse Toolkit is the definitive tutorial on the subject.

Our first sprint on this product was following the first principles as outlined by that book.

We found that the strategy works really well on paper but there are significant scaling issues on the querying side when you throw massive amounts of data at it. A simple sales report over cities for one of our larger shops under moderate load would could take 5-10 seconds to generate, which is pretty unacceptable. Caching would only take us so far because of how much data gets ETL'd every moment.

I definitely don't discount the dimensionally modelled strategy, but to make it proper fast, and not 1990's let-me-hit-report-and-go-get-a-coffee fast, you might need to write your own OLAP stack that's optimized for what you need[0]. I'd also do it in go or c.

Once we ship, we'll do a technical post on what worked and what didn't.

[0]I'd love to be proven wrong on this, so if you can generate fast reports with massive amounts of data ETL'd in real time, I'd love to hear from you. oren.mazor@shopify.com

Re: Shopify POS

#114

Post by jacques_chester »

orenmazor wrote: post #113
jacques_chester wrote: post #104

Earlier quoted context omitted.

Suggestion: provide a dimensionally-modelled reporting schema, it will be much easier to query. Kimball's The Data Warehouse Toolkit is the definitive tutorial on the subject.

Our first sprint on this product was following the first principles as outlined by that book. We found that the strategy works really well on paper but there are significant scaling issues on the querying side when you throw massive amounts of data at it. A simple sales report over cities for one of our larger shops under moderate load would could take 5-10 seconds to generate, which is pretty unacceptable. Caching w…

How massive are we talking? What's your finest grained fact table? Are we partitioning fact tables by customer? What's your current underlying store?

You're actually at the coalface and I'm the bookworm, so I am totally prepared to be schooled on this one.

Re: Shopify POS

#115

Post by rquantz »

nahname wrote: post #17
smickie wrote: post #12

I have repeatedly had clients on a budget choose Magento over Shopify due to a lack of fine grain control. It's very frustrating that they can release a POS system, however fail at, for example, complex sales reports. I wish they'd get it together because they would blow everyone out the water.

I agree, in some areas they are simply amazing. In others, they have a lot of work to do. For example, the devs at my company that have had to use shopify hate it. Their systems are based on hacking javascript for everything. The deployments are very painful too. No way to see what it will look like without previewing it live on the site.

Agree that testing/deployment is a pain. The solution I've come up with is to use the shopify theme manager app, which syncs local files to the online store, then have to two copies of the repo on my local machine, corresponding to the live store and a testing store. It's a pain, but it's Bette than hacking on the live theme files.

Re: Shopify POS

#116

Post by lux »

It's surprising to see no Interac support, since Shopify are from Canada. I don't see any store here using this unless it supports Interac debit cards. I use a Square card reader with my iPhone at a merch booth at concerts, which doesn't need the full POS components, but more storefronts here support Interac than credit cards and you would be turning away a lot of business in a storefront context by not supporting it.

Re: Shopify POS

#117

Post by orenmazor »

jacques_chester wrote: post #114
orenmazor wrote: post #113

Earlier quoted context omitted.

Our first sprint on this product was following the first principles as outlined by that book. We found that the strategy works really well on paper but there are significant scaling issues on the querying side when you throw massive amounts of data at it. A simple sales report over cities for one of our larger shops under moderate load would could take 5-10 seconds to generate, which is pretty unacceptable. Caching w…

How massive are we talking? What's your finest grained fact table? Are we partitioning fact tables by customer? What's your current underlying store? You're actually at the coalface and I'm the bookworm, so I am totally prepared to be schooled on this one.

We started out with mondrian+mysql, but quickly had to drop mysql ("mysql is great until you want to put data into it and then get it back out again" - unattributed, to protect the guilty). Our primary work was with postgresql in the beginning. which, in my opinion, is a pretty solid database to work with overall.

We did partition all of our dimension and facts tables, which helped a great deal. Aggregates were a problem that is specific to us, so we couldn't cheat the usual way that reporting servers do.

The other problem is that our stack is suddenly fully of things like java and olap and postgresql, which made onboarding people who wanted to help, and just debugging, a pain.

I like that comment about the coalface/bookworm, but sometimes it takes somebody on the outside to see what I'm missing.

Re: Shopify POS

#118

Post by saurik »

orenmazor wrote: post #113
jacques_chester wrote: post #104

Earlier quoted context omitted.

Suggestion: provide a dimensionally-modelled reporting schema, it will be much easier to query. Kimball's The Data Warehouse Toolkit is the definitive tutorial on the subject.

Our first sprint on this product was following the first principles as outlined by that book. We found that the strategy works really well on paper but there are significant scaling issues on the querying side when you throw massive amounts of data at it. A simple sales report over cities for one of our larger shops under moderate load would could take 5-10 seconds to generate, which is pretty unacceptable. Caching w…

I fail to understand why waiting five seconds to generate a report that will impact my business decisions is "unacceptable". I have numerous reports I've implemented that take over a minute to generate; they are complex queries that sometimes involve interesting statistics, and the idea of calling them outdated solely because they don't return data in a fraction of a second seems like a fundamental misunderstanding of what businesses do with reports.

Re: Shopify POS

#119

Post by beagle3 »

orenmazor wrote: post #117
jacques_chester wrote: post #114

Earlier quoted context omitted.

How massive are we talking? What's your finest grained fact table? Are we partitioning fact tables by customer? What's your current underlying store? You're actually at the coalface and I'm the bookworm, so I am totally prepared to be schooled on this one.

We started out with mondrian+mysql, but quickly had to drop mysql ("mysql is great until you want to put data into it and then get it back out again" - unattributed, to protect the guilty). Our primary work was with postgresql in the beginning. which, in my opinion, is a pretty solid database to work with overall. We did partition all of our dimension and facts tables, which helped a great deal. Aggregates were a pro…

With all due respect to pgsql, mondiran and mysql - you're using the wrong toolkit. You need a column store, like Vertica, kdb+, TimesTen (now Oracle?), Sybase anytime (I think that was what it was called).

You can do very well at much, much lower cost in the Python world: pandas, PyTables, or even just straight numpy.

Seriously, using any of these would make the report generation time basically zero, and you'd just have to make your ETL work quickly enough to feed it; how well this can be solved depends on how you store the original data ("pre-facts").

The book written by this guy http://blog.wesmckinney.com/ (and the guy himself, if you can get him) will probably advance you way more than experiments.

Re: Shopify POS

#120

Post by scott_karana »

beagle3 wrote: post #119
orenmazor wrote: post #117

Earlier quoted context omitted.

We started out with mondrian+mysql, but quickly had to drop mysql ("mysql is great until you want to put data into it and then get it back out again" - unattributed, to protect the guilty). Our primary work was with postgresql in the beginning. which, in my opinion, is a pretty solid database to work with overall. We did partition all of our dimension and facts tables, which helped a great deal. Aggregates were a pro…

With all due respect to pgsql, mondiran and mysql - you're using the wrong toolkit. You need a column store, like Vertica, kdb+, TimesTen (now Oracle?), Sybase anytime (I think that was what it was called). You can do very well at much, much lower cost in the Python world: pandas, PyTables, or even just straight numpy. Seriously, using any of these would make the report generation time basically zero, and you'd just…

> ...you're using the wrong toolkit. You need...

Ouch. Do you really feel so well acquainted with their internal design that you can use such strong language? It comes across as dogmatic.

Post reply on HN