Eko builds products and technologies that redefine how the new mobile-centric workforce communicates. Companies using Eko have a combined revenue of over $4 billion, and we are looking for enterprising engineers to join the team and help us scale to even more users.
We rapidly release new products, and we’re not afraid to break things in order to try something new. You will be responsible for all aspects of product development, including initial design, testing, and iteration based on feedback. We try to provide the best work environment possible, so you can be focused on delivering outstanding products to our users.
We are looking for talent in the following areas:
* Java / Android application development
* Objective-C / iOS development
* Javascript, AngularJS frontend and Node backend
* Visual / UX designers
* Infrastructure / scaling, specifically with Node
We are a startup developing enterprise applications that make it faster and simpler for people to communicate.
What we need:
We’re looking for a few full stack dev interns for the summer, preferably 12 weeks, negotiable starting date. Our team is currently 4 strong, and you’ll be helping us on every part of the product lifecycle, from concept to implementation to release, and you’ll have a lot of autonomy in the work you do.
We’re a NYC company but we are relocating our office to Bangkok, Thailand for the summer. We'll fly all the interns there and cover all travel / housing / visa expenses. Additionally, you’ll be receiving a very competitive stipend.
If you want an unique summer internship experience and love to travel (for free), this internship is for you. Contact me directly at [email protected] for more info.
Yes and no. The VB article talks about hardware as if Shenzhen engineered everything. In the end, they're just some manufacture copying TI or Qualcomm's reference designs. It's quite sensationalist I think.
Yeah the heading might have been a bit sensationalist, but underneath everybody was logical & made sense. His main idea that hardware-only businesses are dead is right to the point (and so are you in saying that software alone is dead). Its all about integrating everything/anything for that perfect product.
Designing software's easy; writing it is hard and has edge cases and all that fun stuff. ;)
I see things like 'moocow01: free duplication isn't the same thing as it costing $0 to manufacture software. Software is "manufactured" almost exclusively on a one-off basis.
However, there are still similarities. New languages, frameworks, tools, etc, basically do the same thing to software as the $35 tablet represents in hardware. There are a lot of new tools in the past five or ten years that will let you quickly create something that's now seen as basic, but would've taken much more work to duplicate in the past.
In this context design means developing the product, manufacturing means shipping it. Manufacturing software really means copying the binary, which obviously doesn't cost very much...
APIs definitely won't replace bizdev, but you have to admit, for a lot of industries, it's making the process a lot more efficient.
Look at all the companies that are opening up APIs. The New York Times just opened up an API to their entire catalog of articles, definitely wasn't expecting that. These APIs are making the cost of doing business a lot lower.
The NYT example is a bad one because any commercial use of of the API is forbidden per the Terms of Use [1]. It seems like the API would be a pretty bad starting point if you were a business that wanted a relationship with the NYT.
[1] e. YOU SHALL NOT: (i) use the NYT APIs for any commercial purpose or in any product or service that competes with products or services offered by NYT. (from: http://developer.nytimes.com/Api_terms_of_use)
I love bit-banging, sometimes you want to go that route even if the uC does have specialized hardware. I remember having to bit-bang I2C on multiple occasions because the standards are so loose.. good times.
Recently I had to bitbang I2C through a voltage level translating buffer that had a direction setting pin that needed to be manipulated when sampling SDA on input. The uC's hardware I2C block obviously couldn't handle that extra signaling oddity. Not the fastest approach but then this I2C application wasn't that high speed to begin with. Good times indeed!
... and often the specialised hw doesn't go far enough. ie- i2c and spi hw that doesn't have enough buffering to be left on its own. Either we babysit the interface or we can leave it to do its own thing until we get an interrupt for completion. Do a halfway job on the hw and we revert to the babysit case. Not bitter, just ranting.
