• Thursday, December 18, 2014

    #kelsey breseman #community #node.js #node #javascript #culture #tech culture #tech talk #nodeday

  • Cart to Doorstep - Things to consider when selling a product

    Wednesday, December 10, 2014

    12/10/2014– Ken Nierenhausen

    Ever wanted to sell a product online? No not your old Xbox, I mean a product you’re creating. Well the road ahead is can be a bumpy one, and it’s dangerous to go alone! If you’re curious about the process, are a startup looking to sell a physical product, or are searching for better ways to do a storefront or fulfillment, then stay tuned. Take this post as a roadmap for the course ahead.

    There are many steps that take place when going from cart to doorstep. The major parts are the storefront, middleware, fulfillment, and shipping. There are a lot of options in each of these categories, so let’s explore the possibilities.

    The Storefront

    This is the part of the process that you have probably used before. The storefront is the portal from the product to the customer. It consists of two pieces: a place for customers to buy products, and a place where orders are stored for the seller to manage. There are two main approaches: doing it all yourself, or using an e-commerce solution.

    More often than not, storefronts are designed, implemented, and maintained by the seller. They do it themselves, and it’s a complete control solution. This allows for high customizability and complete control over incoming orders. The downside is overhead. Creating and maintaining a storefront from scratch is very time consuming.

    On the other end of the spectrum, there are services that provide an instant storefront. A few good places to start looking are Volusion, Shopify, and Celery. Basically they control the storefront (often with design options), and provide a service to manage incoming orders.

    Volusion and Shopify are big names in this industry, who know how to get you set up with your own storefront. Shopify is slightly cheaper and generally better received, but Volusion has just as many features with great customer support. Along the same lines, Celery is a pre order management system; great for startups who might not have an actual product available yet.

    The biggest thing to remember when determining what to do about a storefront is time. If there’s no time to waste and you need to sell quickly, use one of the e-commerce solutions. They’re easy to set up, fast when it comes to order management, and often have a trial period so you can test them out.

    If you’re considering doing a storefront yourself, look at these solutions again. They offer API’s that can make order management easier. If you want to do it all from scratch, go for it! But expect a longer deployment. Your storefront might be exactly how you want it, but three months too late.

    Fulfillment

    So what happens next? You have a list of orders sitting around. This is where fulfillment comes into play. Fulfillment is the act of taking an order, finding the parts, packaging it, and dealing with shipping. So what are the options?

    The one that probably comes first to mind is in-house fulfillment; aka doing it yourself. As you can imagine, this can be quite time consuming; especially as the number of orders increases. Although this may be perfect if you sell a small number of items or something that’s really customized, it’s not ideal for scale. However it does have the benefit of not needing any middleware (more on that soon).

    There are companies that exist that will handle fulfillment for you. Shipwire, Whiplash, and Rush Order are a few good places to start looking. What these companies do is take your orders from the storefront and get the pieces and parts packaged up and shipped out to the customer. All the hassle of fulfillment is taken out of your hands… if the price is right.

    Shipwire is one of the bigger names here. They handle fulfillment, and have a lot of services (like Shopify and Volusion) already integrated, so there’s no need for middleware. Whiplash is a fulfillment startup that’s a great choice for startups. Rush Order is a little less known, but they have a very personal touch with all their orders; something that might be important to your customer experience.

    So what are the tradeoffs? Here the biggest thing to keep in mind is scalability. Doing in-house fulfillment may be super attractive due to its simplicity and low cost, but if business starts booming you might crash and burn out early. Fulfillment houses have this down. They have the warehouse space, the time, and manpower to get orders shipped; simple as that. However, one caveat to using a fulfillment house is that you have to have middleware.

    Middleware Servers

    Some fulfillment houses have built-in order integration, meaning that you don’t have to set up any middleware. The point of a middleware server is to take orders from the storefront, change them to a format that the fulfillment house understands, and then forward them to the fulfillment house. So what are the options?

    A heavier approach would be having a database on your middleware server. This is great for maintaining history, but a pain to deal with consistency. Introducing a database here means your storefront has a state, your fulfillment house has a state, and now your server has a state. All three of these need to be consistent, and this is going to take time to get right; not to mention dealing with downtime. If you have a use a database, keep these things in mind.

    A lighter approach is setting up a webhook managing server. If your storefront and fulfillment house use webhooks then your server just has to listen and forward accordingly. New order from the storefront? Forward the order to my fulfillment house. Order just shipped? Notify the customer via the storefront order management system. This is lighter than a database, but it still has problems with downtime because webhooks are unique events. If you miss one it’s gone, and now you need to synchronize the states.

    An even lighter approach is setting up a polling middleware server. Basically all it has to do is make sure that the storefront and fulfillment house are consistent from time to time. Although this will also take time to implement, it removes the state from the middleware server. This has the added benefit of dealing with downtime. If your storefront or fulfillment house orders go dark, the middleware will synchronize orders as soon as it hears anything.

    Just remember that downtime is inevitable. Whether it’s your server crashing because of some bug, or your storefront in inaccessible due to a massive DNS DDoS attack on cyber monday. They can happen, and they will happen; plan accordingly.

    Shipping and Distributors

    Shipping a product from one place to another is pretty easy. It’s the options, international orders, and sheer cost that become problems. So how do you deal with this? What are the choices?

    If you’re planning on doing in-house fulfillment, then you’re going to have to deal with shipping. This may be simple enough for domestic orders, but it gets less ideal when things start shipping overseas. Not only will there be high international shipping costs, there are also going to be import tariffs that differ from country to country (sometimes as much as 2x the cost of the actual package!)

    This may work for a company with low volume or highly customized sales, but more often than not it’s a headache. Your customer is going to be dealing with customs themselves, and this takes away from their experience.

    Another thing to consider if you’re doing in-house fulfillment is distributors. Distributors will take your product and sell it in another country. The benefit of distributors is that you and your distributor deal with international charges, not the customer. However the downside is that distributors take a cut of the profit. It’s not cost effective to use distributors if your shipping costs are less than it would be to pay them.

    If you’re using a fulfillment house, make sure to ask about distributors. Fulfillment houses often have warehouses overseas that they use for international distribution. If they do, see if there are any additional charges for international orders. If they don’t, make sure you understand that your customer will be dealing with customs.

    Shipping and distribution is a tricky trade off between financial management and end user experience. Is one more important than the other? Maybe, it really depends on your customer and your wallet; keep those both in mind.

    Conclusion

    Selling something online is a process, not an ebay account. There’s going to be a lot of decisions made that are highly dependent on your timeline, business model, and finances. However taking a little time to set up a storefront and supply chain in the beginning will save you a lot of headaches down the line.

    Just remember the big points from each part: Storefront - time to market Fulfillment - scale Middleware (if you need it) - murphy’s law Shipping - customer satisfaction

    As always, if you have any questions, comments, concerns, or hate mail, feel free to contact me at ken@technical.io

    Cheers,
    Ken

    #Ken Nierenhausen #tessel #technical machine #fulfillment #shipping #storefront

  • LuaJIT on Tessel: First Steps

    Tuesday, November 18, 2014

    11/18/2014– Updates

    Hello, Tessel aficionados!

    We recently released a 2-3x performance improvement to Tessel, in our first step toward integrating LuaJIT as part of our JavaScript stack. This is a big step for high-level languages on embedded devices, and is key to some much bigger (order of magnitude) performance upgrades we’re working on over the next month. Update normally with tessel update, and read more about it on the blog.

    We also continue to develop Fractal, our planned revolution in hardware production tools. We have decided to create our proof of concept on the Atmel’s SAMR21, and are fleshing out details of the system as a whole. Fractal is still in the design phase, and is being developed openly– so please read about it and discuss with us here.

    Finally, the company has made a new hire! Please welcome the eighth member of our company, Kwyn Alice Meagher. We’re very excited to have her as a full-time web developer– expect to see site improvements soon! (We’re still hiring for various other positions, including 2015 summer internships– check out the jobs page for more details.)

    Never a dull moment here at Technical Machine– here’s what else has been going on:

    We’d love to hear what you think about all these changes and ideas– get a discussion started on the Forums!

    All the best,
    Ken, Jia, Kevin, Tim, Jon, Kelsey, Kwyn, and Eric

    #update #updates #luajut #lua #javascript #embedded #fractal #hiring

  • A New Engine for your Tessel

    Tuesday, November 11, 2014

    11/11/2014– Tim Ryan

    When designing Tessel, we grappled with some very unique constraints for a developer platform. Most microcontrollers weigh in at perhaps a few dozen kilobytes of RAM, and a small factor more Flash. The average amount of JavaScript in a single webpage exceeds the amount of space in most microcontrollers, including the Tessel’s Cortex-M3, which has only 200kb(!) of memory on-chip.

    We didn’t need to make a full PC to make Tessel an interesting prototyping platform for web developers. There are plenty of ways to have JavaScript co-exist and communicate with embedded devices, for example Firmata or Raspberry Pi’s GPIO ports, but few products allow you to use existing software development tools to write code that directly interfaces at the level of a microcontroller or signal interface to other ICs. (An idea we’re pushing further with Fractal. Read more.)

    To push JavaScript as a language down to this level, our major hurdle was getting an embedded platform to run code at all. Despite its surface similarity to C, dynamic languages like JavaScript, Python, or Ruby require a lot of overhead just to run a line of code. Usually this takes place in a “virtual machine”, a language interpreter that provides the standard libraries, handles dynamic typing (5 + 5 and "5" + 5 mean different things in JavaScript), and of course memory allocation like garbage collection. Emulating a language in this way can naturally be more CPU and memory-intensive than compiling.

    The problem with running JavaScript on a target like Tessel is that every commonly used JavaScript engine has been refined and tuned for Desktop PCs, with gigabytes of RAM and fast network connections. But not all VMs are created equal; they are tailored for wildly different use cases, including embedded platforms.

    Fortunately, JavaScript has some essential similarities to the programming language Lua. Lua is a dynamic, lightweight programming language with extensible semantics that has seen broad use as scripting language in video games, routers, servers, and much more. Much of its popularity is due to how simple it is to embed. Lua is composed of a few dozen files written in portable C and has no external dependencies. Thus with Lua, adding scripting to a project becomes as simple a proposition as including another C library. That Lua supports many similar properties to JavaScript—first-class functions, null/boolean/string/double/object/array types, and can be changed at runtime to act differently—made it an amazing starting point for exploring how to make a JavaScript-compatible, embedded runtime.

    Heavyweight JavaScript engines like V8 and Spidermonkey are also embeddable, but where Lua shines is its low memory profile (taking only a few dozen kilobytes to start up instead of several megabytes) and simplicity. Thus, our first real demonstration of Tessel was in summer of 2013 getting Lua running on the LPC1830 (Tessel’s CPU). After that, it was “straightforwardly” a matter of closing the gap between Lua and JavaScript.

    Because Lua is extremely extensible, allowing modification of everything from basic add operators to whether primitives act like objects, a year of effort has resulted in a runtime that emulates many real features of Node.js with only a fraction of the resources Node requires on PC.

    Just in Time

    One year later, the landscape is much improved: several stellar alternative JavaScript engines are now freely available and freely licensed. Among these are projects like the Espruino VM, optimized for size and memory conservation, and Duktape, a JS engine designed for embedding into C. Meanwhile, Tessel’s JavaScript engine, dubbed “Colony”, leverages Lua’s VM and ecosystem to provide a Node-like environment that works across PC and embedded targets. But while Tessel is not lacking in memory, it is lacking in one of JavaScript’s biggest modern advantages: speed. So over the past few months, I’ve experimented in what would bring Tessel up to speed (literally) with other modern dynamic languages, starting with a foundation lauded for its speed and minimal codebase, LuaJIT.

    LuaJIT is a combination of a few components: a parser/compiler converting Lua source into (LuaJIT’s own) bytecode, an interpreter for running this bytecode, and then a JIT (just-in-time compiler) for optimizing this bytecode into machine code at the lowest level. If you’re not familiar with a JIT, imagine a compiler that runs alongside your code, observing your code as it’s running. If it sees any loops that look intensive, are called often, and use similar types of variables on each iteration, it can bundle these assumptions up as compiler “guards” and generate low-level machine code that acts much more like C than a high level language. If, while your code is running, one of those guards fails (the variable i is no longer a number, because we suddenly assigned it to be an array!) we jump backward into interpreting your code one line at a time. This is one of many optimizations that happen while your code is running inside a VM with just-in-time compilation.

    But why pursue LuaJIT? We’ve reached the limits of what our old runtime can do while sacrificing speed to emulate JavaScript compatibility. We’d like to implement many pedantic features—getters/setters/enumerable/writable/configurable properties, proper null values to arrays, and speedy execution in modifying binary data—while making code run much faster, and to top it all off, keep a freely MIT-licensed codebase. By building on top of some of the best technology that exists today, we can make it even more useful and flexible to programmers of all kinds, including Lua programmers interested in targeting microcontrollers.

    LuaJIT on Thumb

    As of today, you can update Tessel to a new build built on LuaJIT’s codebase instead of the classic Lua VM from PUC-Rio by running the usual tessel update. This doesn’t enable the just-in-time compilation I described; we are working on porting this. For now, LuaJIT’s codebase and interpreter (the first step toward speeding up your code) are enabled and yield a pleasant 2-3x speed improvement. We’re working on porting the JIT component itself to leverage interpreter and speed up code execution by orders of magnitude, so stay tuned.

    What does this mean for Tessel users? Today, a small speed improvement. Next, we can address large incompatibilities in how Tessel runs JavaScript in a rigorous way. We can speed up all code by leveraging LuaJIT’s interpreter, fast internal function paths, and eventually JIT to perform machine code assembly for JavaScript code. In addition, compilation of JavaScript on Tessel (enabling things like Function constructors and eval()) can be written to target LuaJIT bytecode directly, shortcutting our process of compiling to JavaScript to Lua source.

    Outside of Tessel, this throws Colony’s hat into the ring as a JavaScript engine with a focus on embeddability and performance. (You can test out Colony on PC today by cloning https://github.com/tessel/runtime and following the instructions. Colony’s JIT is enabled on PC, so benchmarks run quite fast considering its size.) Alongside the other great engines mentioned above, this furthers JavaScript’s inroads in enabling web programmers to prototype high-level ideas in standardized languages for every part of the stack. In 2014, I can’t think of anything cooler than that!

    I’ll be writing more on the technical details of this LuaJIT port in my next few blog posts, so stay tuned.

    #Tim Ryan #Tessel #Technical Machine #JavaScript #Hardware #Lua #LuaJIT #Colony #Performance #Speed #Bytecode #Embedded #Microcontrollers

  • New Hire: Kwyn Alice Meagher

    Wednesday, November 5, 2014

    (aka HarleyKwyn)

    11/5/2014– Kwyn Meagher

    Hey there!

    I’m Kwyn, aka HarleyKwyn, from Sunnyvale, CA, the original Silicon Valley. Unlike the majority of the Technical Machine crew, I do not hail from Olin College and instead graduated from University of California, Merced’s Materials Science and Engineering program with an emphasis in nano-technology.

    Specializing in carbon nano materials, I fabricated graphene transistors and simulated nanoscale organic photovoltaic cells using MatLab, and COMSOL. I spent the majority of my time programming simulations, which I enjoyed. However, I did not enjoy the constant uphill battle of submitting lengthy proposals. Proposal writing took up half my time and it was a gamble whether or not they would get funded. When funding was awarded it was frequently less than we needed to run our experiments. This led me to enroll in Hack Reactor once I realized the sad state of academia as a whole. So instead of climbing the ivory tower, I’ve joined the ranks of the Technical Machine team.

    While at Hack Reactor as a student and Hacker in Residence (Hack Reactor’s equivalent of a graduate program), I did a variety of projects. The first project I tackled with a group of other engineers was competing in a Kaggle competition to classify galaxies, leveraging the power of a supercomputer to give us an upper hand since none of my team had done machine learning before or written a lick of code in python. I’m proud to say that we beat out university teams in the two weeks that we spent on the project.

    My second project, and personal favorite, was Visual Interpreter, an interactive visualization of the JavaScript interpreter. Visual Interpreter hooked into a JavaScript interpreter written in JavaScript (very lisp-y). We built a visualization of the scope hierarchy and it could highlight when closure scopes were created and tell you when objects were === to each other.

    With my background in machine learning and research, it’s surprising that I originally took a strictly front-end position at Uber right after finishing Hack Reactor. I did a short stint there before I had coffee and a conversation with Jon. After our conversation it was obvious to me that my heart really belonged to Technical Machine and Tessel. My varied background in nano-engineering, teaching, and web engineering, lent me a special mix of skills that fit well with Technical Machine’s mission.

    I’ve been attracted to mentoring students–historically in physics, nano-engineering and software engineering, though that’s just the beginning. I take great pleasure in teaching and learning from others so I hope to see you all in the future at conferences, hack-a-thons and meetups. Stoked to be part of this amazing team and look forward to working with all of you via twitter and the forums. Feel free to reach out to me on twitter @HarleyKwyn or via e-mail at kwyn [at] technical.io

    Happy Hacking

    #kwyn meagher #tessel #technical machine #hack reactor #harleykwyn

January 2018

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013