Frencil

One gotcha is that you won't get any CSS this way, so all styling has to be done via SVG props.

There actually is a way to bake stylesheets directly into the SVG in a way that at least Inkscape can read, but it's tricky. We're successfully doing this in a graphing library tuned for genetic data that's built on top of d3 called LocusZoom.

The first step is to get the content of the stylesheet into a string. We do that here with a CORS request in case the stylesheet is being loaded over a CDN, as javascript won't be able to access the content of CDN-loaded stylesheets from document.styleSheets:

https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a...

Since the stylesheet doesn't change once the page is loaded this only needs to happen once. From there, in our case, we have a dynamic/interactive SVG plot so the download needs to bundle up the current state of the SVG on request. Here's the method that does that:

https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a...

Other than what no doubt looks familiar for pulling the raw SVG markup into a string we also insert a tag right after the opening <svg> tag that looks like this:

"<style type=\"text/css\"><![CDATA[ " + this.css_string + " ]]></style>"

Where this.css_string is our stylesheet content. We then base64 encode the string and stick in the href of an <a> tag styled to look like a download button as seen here:

https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a...

The end result is a download SVG link/button that is 100% client-side with our chosen stylesheet embedded.

Now, I have noticed that some styles defined in the stylesheet are valid in the browser but fail in InkScape and other SVG viewers. A prime example would be setting a stroke or fill to "transparent". InkScape doesn't interpret this properly and you can end up with solid black, just about the exact opposite of transparent. Keeping this in mind I stick to defining explicit "fill-opacity" and "stroke-opacity" values in the stylesheet for SVG elements and everything plays nice.

A working demo of this can be seen here: http://statgen.github.io/locuszoom/plot_builder.html

Xively was one of the services we used as inspiration for Phant / data.sparkfun.com. Before they were Xively they were Pachube and things were easier to work with and free. Then Xively gobbled up Pachube and things got all business-y. Thus Xively has been an example of how we didn't want to build it.

This is a bit of a false dichotomy here, as we do have occasional work from home which varies between positions and departments. That perk is a separate concern from the dog perk. I know of some employees who do choose to favor the former to opt out of the latter (working from home to be with their dog) because they don't want to bring their dog to work for whatever reason.

In all fairness it used to be more of a waste of time (as mentioned in the post it got progressively worse and widely viewed as a waste of time) until the tribunal came along. Under that setup it's 30 minutes of 5 peoples' time once a month, which is pretty easy to swing.

This is perhaps one of the more succinct ways of summarizing our core reasons for the switch. There's a lot more to it than that, of course, but in a nutshell we saw the upcoming scaling of our data footprint and complexity and wanted to use (what we evaluated to be) the better tool for the job.

Inventory location is one of many, many problems our ERP system is tasked with. And we've looked at a lot of software packages over the years, both proprietary and open. In terms of open software the options are actually pretty limited and have the potential to introduce more problems with integration and customization than they would purport to solve by bringing in new suites of features. What is less limited and truly abundant are examples of other companies in our same position that went full-bore into an off-the-shelf solution and ended up severely disrupting their business operations and aborting transitions.

I presume you're recommending PostGIS because of the allusions to the inventory location problem. While better modelling of geo data would be nice it's kind of a different concern. For us inventory location isn't about where on Earth our inventory is, or even where geometrically it is relative to something else, it's about where in a hierarchy of named locations it is. For instance: we have 10 of widget X in the storefront stock room, row F, rack 17, shelf 3, bin 1. Or we have 22 of widget Y in the receiving room on the quarantine table. Stuff like that. When modelling that many semantic nested locations and all of the transfers of items between them the primary issue is scalability and speed, not so much modelling geographic data.

These are all very good questions and underscore the need to come to an interview prepared to do no less.

As a manager who frequently interviews developers nothing is more deflating than an applicant who, when asked if they have any questions, fumbles an awkward "no, not really" and the interview comes to an abrupt end.

Amazing how the insides of these chips are composed of similar looking traces and microcomponents to the PCBs that house them on a larger order of magnitude.

I'm booked for a tour in April and had no idea it was scheduled to be shut down. What a stroke of luck! Here's hoping we get a more in-depth look than we would have during normal operation.

We had a similar situation several years ago with our site:

http://www.sparkfun.com

And this Chinese knock-off:

http://www.geeetech.com/

Not only did they rip off our design but they also use a bunch of our product photos. We himmed and hawed about doing something about it but ultimately realized there really was nothing we could do to enact any real change. At the end of the day any site's CSS is open source by virtue of the technology (and our product images were already CC BY-NC-SA 3.0 licensed anyway).

So we said screw it. We decided that the best way to assert this design was our own was to run a better website, and more so, just run a better business. In the end it hasn't dented our traffic. GE Tech looks sort of like SparkFun but it sure is a lot more rough around the edges. We've continued to refine our design with less of a Geocities palette while never really caring what those Chinese ripoff artists are up to. It's irrelevant. We'll continue to define our web presence without using them for context, and if they continue to grab skin-deep features from us then terrific - we're a source of inspiration and should be proud.

The retail comparison is apples to oranges, in my opinion. Amazon is purely eCommerce, no brick-and-mortar, so the comparison is strongest when considering other eCommerce outfits.

Consider a site like NewEgg. At ~250M annual revenue they're an appreciable fraction of Amazon's size with a lot of catalog overlap. Certainly for commodotized consumer electronics they are direct competitors.

I think the difference the author is trying to articulate is that NewEgg's overlap with Amazon (for example) is considerably less impactful on Amazon than, say, Samsung's overlap with Apple. Phones and tablets are a huge proportion of Apple's profit generation - an area where they cannot afford to be dethroned. With Amazon and consumer electronics, having NewEgg overtake more of their sales in that area would hurt, but Amazon has such a vast catalog that the company, investors, and stockholders know they'll soldier on in a variety of other markets.

That's Amazon's power. Apple's no one-trick pony but they are a pony with a countably limited number of tricks. Amazon is a platform for selling anything and everything. They've abstracted out their distribution network to adapt to selling the Next Big Thing before it's even been conceived. Competitors can take a swipe at a chunk of their market but at the end of the day they're in so many markets that it's a truly monumental task to dethrone Amazon in any meaningful way.

SparkFun Electronics (Boulder, CO)

Looking for a full time web application developer. Debian/Nginx/PHP/MySQL stack with a dash of MongoDB. Heavily open source environment (SparkFun is a leading in Open Source Hardware) and our dev shop is just as committed.

Free beer on tap, dogs allowed at work, excellent employee discount and free or heavily discounted access to tools, resources, and learning about electronics and physical computing. Using spare cycles for tinkering is encouraged.

Full job posting with application instructions:

https://www.sparkfun.com/jobs/30

Note: forking a Git repository is part of the application process.

Another excellent post by Rands. Much of his guidance on conducting 1:1s with developers I gleaned from his book Managing Humans. The note in this article on asserting "I will not be the next one to speak" is a great piece of advice though; something I'll have to start doing.

The number one rule for KickStarter is that it is NOT eCommerce. When a campaign operates on the mindset that it's a platform to sell goods, and when backers also operate on that same premise, both parties end up on the hook for something they weren't expecting.