Launch HN: Convictional (YC W19) – Supplier Network for Retailers - <AUTHOR> Hey HN,
We're Roger and Chris, co-founders of Convictional (https://www.convictional.com/). Convictional makes it possible for online retailers to find, onboard, and integrate with third-party suppliers. We do this by connecting them to a network of suppliers that manage the inventory and ship those products directly to the end consumer on their behalf.
The idea behind Convictional started when Roger worked at GNC, a large natural health products retailer, at the age of 17. One of the biggest challenges was onboarding. As a retailer, you either buy inventory or ship from third parties ("drop shipping"). They decided to expand their catalog by selling some products that were shipped directly by the supplier. To do this, GNC required both sides to implement EDI (an old school, pre-internet data format for exchanging information between business systems) or manually exchange flat files for things like inventory, orders, and product information. We only got a fraction of the total vendors we wanted to onboarded because of this.
A few years later, we met while working together at Shopify on B2B. There, we saw that the challenge of onboarding third-party brands still existed for retailers, and people were experiencing the same pain trying to use EDI to get it done. Online retailers also didn't know how to find third-party brands to work with or struggled to dropship with existing partners.
Convictional's product is an app and API that syncs product information, inventory, orders, fulfillments, and payouts between online retailers and all of their suppliers. We do this by integrating with the systems used on both sides through an API or pre-built connectors to ecommerce platforms like Shopify. We later added a way to find suppliers after online retailers told us that they also wanted to access a network of connected third-party brands.
We're using a generalized data model in the middle with a bunch of mapping, transformation and transmission steps on each side. Similar to what EDI does but much easier to set up. The goal is to turn what today requires a 6 month IT project into an email invite and an app install. It's an industry that has existed since the 60s, and it's probably the last major software industry that touches commerce but has not meaningfully been updated.
To do this we developed our own queueing system in Go that can map events from buyers and sellers, transform them from the source format into the destination format, validate and apply a bunch of domain-specific business logic to make sure what crosses the bounds of buyers and sellers actually makes sense, and then send those into another queue that passes it to their partner. We basically have to control the state of three systems for each transaction. Before us, it could take up to 24 hours to know whether that loop succeeded or not but we're able to do it within a few seconds. There are a lot of real life things that enables, but mostly it enables a good experience for the buyer's ultimate consumers and less inventory for both sides.
Our belief is that online retailers will be less inclined to take on inventory. That's why we started by building the tooling necessary to automate dropship. Over time, we'll launch tools that can enable more forms of B2B trade in a way where regardless of IT skills, both sides can have systems doing their purchasing and selling for them. Today large companies enjoy significant advantages through this integrated approach, and soon every buyer and seller can too.
Brands and suppliers can join our seller network for free. If you make or sell physical products on an ecommerce platform, consider joining. For online retailers, we charge a flat monthly fee and a percentage of GMV, depending on volume and which work gets outsourced to us.
If you have questions, we'll be here to answer them. We'd love any feedback, ideas, and/or EDI horror stories that you may have as well. Thank you! <comment><USER2> I think as trade tensions increase with China, there is going to be a huge market opportunity for people in the US to start overtaking some of that business that AliBaba currently owns. As a US based solution, you guys are tapping into a real opportunity here. Good luck.

* Quick idea, you guys should buy a warehouse, stick it in the middle of Odgan Kansas, and charge suppliers to store their stuff there, than ship it for them. With that location you can send almost anything to almost anywhere in the US in 2 days on ground as long as you get it out quickly, and you directly inject it into the carriers hub.

<comment><USER3> It's funny you say that because some of the largest distributors in the world are basically what we have + a 3PL facility attached to it. Our hope is to partner with distributors who do the physical stuff and provide better software, which so far is working pretty well. We would be really out of our depth on the physical side of things at this point. Shopify just waded into their own 3PLs though which is interesting. Shipbob also does this quite well.

<comment><USER4> Yep it seems like Deliverr and Shopify are trying to pry sellers away from Amazon FBA.

I'm actually working on an open-source fulfillment system for Shopify where users can source their inventory from ShipBob, Deliverr, any custom 3PL:

[https://github.com/openshiporg/openship](https://github.com/openshiporg/openship)

Could we integrate with Convictional?

<comment><USER3> Yes: [https://docs.convictional.com/](https://docs.convictional.com/) although it's worth a conversation to figure out the easiest approach. firstname.lastname@example.com

</comment></comment></comment></comment><comment><USER5> What's your relationship with carriers? I spent a bit of time with "Large E-commerce company" We would have 3rd party sellers not delivering on time (or sometimes not delivering at all). They would claim FedEx/UPS was late or FedEx/UPS would claim it was on time but the 3rd party shipped with a different account than "Large E-commerce Company." It was a big headache for the people ensuring delivery and bad customer experience. It sounds like you want to sit as a sort of middle layer between sellers and supplies to ensure data quality. (is that correct?) If so, do you plan to integrate with carriers or how do you plan to address that.

<comment><USER6> Ah, sounds familiar! We didn't use carriers managed by the dropshipping supplier but rather in-house managed ones. Helped but made edge cases not covered by existing in-house solutions a real pain.

I like what I see so far from Convictional. But one thing that puzzles me with similar start-ups is the disregard for actual operations. Has nothing to do with Convictional so. But since I see that as an opportunity I put my money where my mouth is.

<comment><USER3> I agree with this. I don't think it's a software only problem, and we ran business units like this before we got into the software side. The operations side is harder (generally speaking) it's more that the enablement tech that exists isn't working for current sellers. That's partly on us to fix, and partly endemic to small sellers not having B2B sophistication. So solving the problem also requires solving the physical logistics problems and education gaps that exist. So far we're just focused on the software and to a lesser extent education. There are really good operators out there that we're trying to partner with, who tend to be weaker at the tech.

</comment></comment></comment><comment><USER7> Congratulations on the launch.

Would it be fair to say Convictional operates in a similar domain as [https://supplier.meesho.com](https://supplier.meesho.com) does in India? If not, what are the differences?

Is EDI specific to North America or a global phenomenon?

\---

The hamburger-menu doesn't work when I block google-analytics and hs-scripts domains.

The links in the footer viz _Retailers_ -> _Marketplace Platform_ and _Brands & Suppliers_ -> _Brands_ simply load the homepage. Is that intentional?

Personally, I believe _Convictional connects online retailers to brands. Focus on selling, let brands handle fulfillment._ is wayy better than the abstract _Become the Digital Destination for all of your customer needs without inventory risk._

Another nit-pick is that the entire page is all about retailers, but the top section has a link to _Solution for Brands_ and it isn't clear really why the link exists top-of-the-fold when the entire page has no copy re Brands? That, or I hopelessly misread the copy.

\---

All the best!

<comment><AUTHOR> EDI is a global phenomenon. There are different standards and it applies across industries. For example, X12 is the North American standard of EDI. It's used in B2B trade, banking, health care, insurance, etc.

Meesho is interesting. It's like an ecommerce store in a box.

We aren't a conventional marketplace ourselves and we integrate with the systems that both the sellers and buyers are using. On the network side, we make introductions to buyers and sellers in our network rather than listing products from sellers on a mass marketplace (like AliExpress). We basically vet each retailer to see which suppliers in our network would make sense for them then make introductions if there's a fit. We also tend to be focused on larger retailers and distributors rather than people who are just getting started in ecommerce.

Thanks for the feedback on the site. Will fix the hamburger menu too. Good catch.

I like your copy suggestion. It makes sense for people who might be new to dropship. The "digital destination" line came from larger retailers we talked to that wanted to expand their existing product catalog, so we aimed that at them. They tend to already do dropship today with larger suppliers, but they struggle with onboarding smaller ones. The thought of having a wider assortment of products is usually what initially piques their interest. That starts a conversation around new tools that they could use.

</comment></comment><comment><USER8> Cool business model and something that makes sense for more online retailers to adopt. My question is how do you differentiate yourselves from Mirakl ([https://www.mirakl.com](https://www.mirakl.com)) and F13 Works ([https://www.f13works.com](https://www.f13works.com))

<comment><USER3> We have never seen F13 in a deal but they do seem like a valid alternative. Mirakl starts at $500k/year and minimum three years, and are pretty focused on existing offline retailers moving online and going marketplace, so they are pretty limited in who they can work with.

Our general feeling is that niche / values based aggregators are where the puck is going, as opposed to everyone being a worse version of Amazon, where people are shopping their values more often.

The other thing I would say, not to pick on any one of those offerings, is that we actually have a bunch of prebuilt seller apps to making onboarding easier. To our knowledge, that's unique, most of them just have an API and CSVs where as part of our product includes the seller side integration. Merely offering an API instead of EDI doesn't necessarily solve the problem, most of the sellers don't have ERPs or in-house IT at all so facing down JSON via API instead of X12 via EDI is equally impossible for them.

</comment></comment><comment><USER9> Is this more for established retailers or mom/pop shops who are wanting to get into shopify? Is this similar to Oberlo except not 100% reliant on aliexpress and more cross-platform support?

Have you thought about creating retailer plans for hobbyists/new entrepreneurs who want to just test a few ads/products on fb, then signup for bigger plans later on, or maybe a freemium/pay-per-sale model?

I ask as a developer, who's thought about doing dropship quite a bit (whenever I get dev burnout), original plan was buy shopify account, onboard products from oberlo, and get some product vids up on fb ads for the cooler products.

<comment><USER3> The Shopify/Oberlo buyers only sometimes end up being durable. For the ones that are, they come to expect better in terms of ship times, terms and other business things that aren't well handled by Aliexpress dropship. So generally speaking, buyers would graduate to us after they get to six figures. For sellers it's free so they can be big or small.

</comment></comment><comment><USER10> Love seeing products that tackle the un-sexy (fulfillment) side of sexy industries (e-commerce). Keep it up!

</comment><comment><USER11> I had the pleasure of working with Chris at a startup competition in undergrad. Congrats to Chris and team, may success continue to come your way!

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER12> I love this idea, it's kind of like an affiliate network for physical goods. The delivery time is probably the only thing the scares me.

<comment><USER3> Us too. We're keeping data on sellers and their fill, ship and complete time. Fill time meaning how fast they fill when the order gets to them, ship time meaning how long it takes from the order time until the shipment occurs, and complete time meaning from time of order to time you get notified.

</comment></comment><comment><USER13> OPs: I feel like we might have some synergies if you extrapolate a bit out from what our product does on its surface. I can't put my finger on it exactly though. See the How can I list my shop question at [https://attic.city/owners](https://attic.city/owners).

<comment><USER3> Yeah Attic sounds interesting and relevant. In general we're a platform and vertical agnostics enablement solution that doesn't suck, and so it's possible we could help you integrate directly with the sellers of the antique furniture. firstname.lastname@example.com and we can talk more offline.

<comment><USER13> Will do. We're already "integrated" with nearly 1000 stores in 13 markets with upwards of 300,000 indexed products. Currently just a B2C focus though. I think there's another possible angle here.

</comment></comment></comment><comment><USER14> Hi Roger and Chris!

I have read your landing pages but still not understanding how you are going to make leaps and bounds ahead of competition trying to add "selection"...

I see your biggest challenge is onboarding suppliers that are non-tech or don't understand eCommerce platforms.

Otherwise you're onboarding brands that are already listing their products with other dropshippers?

I run an a consulting agency for Amazon suppliers, essentially holding their hand through all things related to Amazon and eCommerce strategy.

I also run a marketplace store for when my brands don't want to have their own Amazon relationship.

We haven't pushed any brands to oberlo because it seems like a massive headache with low sales opportunity.

Who is your "perfect" brand?

<comment><USER3> Agreed re: Oberlo. So far it's fashion, furniture, homewares or other durable goods who have good reviews, started directly to consumer and then plateaued, and have US-based shipping. Even better if the product is made locally but that's less common.

Generally we can help them with a lot more than enable drop ship, which could be underwriting their receivables, doing EDI integration, setting up a B2B program, etc.

It's less focused on marketplace sellers and more directly on the company that sources or makes it. Hope this helps.

</comment></comment><comment><USER15> Drop shipping has been the bane of my online shopping experience. Products are often not as advertised and returns can be a huge hassle, so it has become a word I avoid. How do you plan to raise confidence for consumers in this practice?

<comment><USER3> We actually agree with this, we saw that inside Shopify. Bigger retailers are getting smarter about this and enforcing vendor SLAs. Meaning requirements like:

1\. Accurate product listings

2\. <24 hour ship times, enforced

3\. No manual steps, only automated / integrated

4\. Easy returns, funded by sellers

5\. Sellers based in the same country

Drop ship can range from very small and generally not very durable online retailers to massive and very sophisticated retailers. In the case of the sophisticated ones, you may not even know the difference. Amazon for example has been drop shipping a lot more, but because of their vendor SLA people can't tell it's not from FBA. It's mostly just about good vendor SLAs, local suppliers and short ship times.

The other thing we're seeing is a continuum where people start out drop shipping, and then move to wholesale when the volume grows. That way 1. Consumers get access to smaller / newer brands early and then 2. Eventually the experience gets more controlled. We do both, just generally because our customers are growing but also because you really need both to make the experience good.

<comment><USER6> True for Amazon. There are cases, after some really hard internal fighting, of Prime enabled Dropshippers, meaning you even see the "order in x minutes for next day delivery" message. So it is definitely doable, hard work but doable. And every tech improvement to make that easier is very welcome!

</comment></comment></comment><comment><USER16> Looks awesome Chris... what do you think your moat/defensible advantage is though? Can't Amazon or Shopify just replicate what you do with their network of retailers/sellers?

<comment><AUTHOR> It would be unlikely for Shopify to build integrations with other back office systems that compete directly with Shopify (e.g. BigCommerce), so there'd be a cap on the amount of integrated trade that could happen. A defensible trade network would need to be independent and connect to any system that buyers and sellers use. We'll just keep making it easier for businesses to trade irrespective of the systems they use and their preferred sales channels (e.g. dropship, wholesale, etc.).

</comment></comment><comment><USER17> The name is interesting. The connotations for me are of either something in the justice system, or something oddly religious. I'd never have guessed that it was b2b related.

What's the story behind it?

<comment><AUTHOR> Before Amazon was named Amazon, one of the original ideas for its name was Relentless.com (btw, the domain relentless.com still redirects to amazon.com). We liked the word "conviction" and what it represents. Conviction.com wasn't available, but convictional.com was available. So we bought it.

</comment></comment><comment><USER18> Minor nitpick but: your logo seems to blend into the background because there's not enough contrast. Also, seems like the top is cut off if you zoom enough (it's also very tiny) [https://imgur.com/a/gIgGpRp](https://imgur.com/a/gIgGpRp)

Congratulations on the launch and best of luck for the road ahead!

<comment><USER3> Our logo is not great and also a carryover from a prior startup one of us had. We should definitely update it...

<comment><USER18> I feel that would be a good idea! I didn't really find a connection b/w the company and logo so had just flagged it off as abstract.

Not sure if this is the correct place, but I do design :P

</comment></comment></comment><comment><USER19> Would this work for just existing products in the supplier marketplace? Or would it somehow enable custom products to be dropshipped?

The advantages for the retailers seems great but what about advantages for the suppliers? Eventually if enough people started using one supplier, they would have so much inventory they would need another warehouse.

<comment><USER3> We built it to enable people to onboard their own suppliers to the network, so it works with existing or net new members of the network and everything is centralized either way.

For the suppliers, they're often being asked to participate in lots of different flavors of "vendor enablement" program. Most are oppressive, involve EDI integration, 40 page vendor agreements and opaque invoicing. We're trying to get rid of those things, and ideally give them a way to have one integration for all of this stuff.

</comment></comment><comment><USER20> Congratulations on your launch. How many suppliers are in your Brand Network? Is it possible to obtain a list of active partners?

<comment><USER3> We haven't been sharing so at this point "hundreds", if you want to email firstname.lastname@example.com we can share the ones relevant to your vertical.

</comment></comment><comment><USER21> Congrats on the launch, team! Excited to see you guys take on this space with so much prior experience & knowledge

<comment><USER3> Thanks Phillip, we really like using Doppler too :)

</comment></comment><comment><USER22> My first thought on reading the name was perhaps this was a business whose competitive advantage was hiring convicts and other people who are disadavantaged in the job market - I'm not sure how the name Convictional relates to the product?

<comment><AUTHOR> People in our YC batch thought that we made software for convicts. We just liked the word conviction and what it represents.

<comment><USER18> I first read it as Convectional and I thought maybe that represented your transport model (like the convection heat transfer)

</comment></comment></comment><comment><USER23> Congratulations. I hope you can put Ariba Network out of business.

<comment><USER3> Ariba is definitely a funny one. Our sense is that some of these trade networks are immortal. That said, the experience has to get better, and if it does, more trade happens, so it's by no means zero sum. The other thought I have is that we're quite sure being tied to a particular "island" is not optimal, it's better to be independent and let the "islands" build the functionality buyers and sellers want in their business. We want to stay a bridge, and stay agnostic.

</comment></comment><comment><USER24> This looks cool and can see many use cases. Hingeto I believe is also in the space. How do you deal with shipping multiple items in an order from different suppliers?

<comment><USER3> We can split and route orders to various suppliers. One of our first orders was 20 items from 19 different suppliers, so through that experience and much pain we made it seemless for the consumer. One page for order updates, unlimited different vendors. That ended up not being as hard as making the experience on the consumer side good, so that they didn't get 20 different update emails.

<comment><USER24> I meant more on the shipping side. It must be more expensive to ship 19 different shipments?

<comment><USER3> Yes it's definitely more expensive although often offset by who is taking the margin on the order. When you average it out it ends up being 5-10% of retail for shipping depending on the vertical which often gets priced in by sellers.</comment></comment></comment></comment>


JSCity – JavaScript code visualizations using Three.js - <AUTHOR> https://github.com/aserg-ufmg/JSCity/wiki/JSCITY/mobile=1

<comment><USER2> It's unfortunate that the author has chosen to wait with giving access to the source code, insisting that it still needs to be "cleaned up".

I can understand the reasons (in most cases it seems to be vanity), but it would often be best to just give access and clearly mark it 'work in progress'. Open source miracles may happen.

<comment><USER3> The problem is most people just criticise/tear-down instead of actually improving open-source projects (just read the Show HN section here...). Building open source projects requires a positive attitude and early stage comments can be discouraging.

</comment></comment><comment><USER4> Cool to see isomer[0] on here :) Does the visualization mean I'm doing good? Haha - lots of similar-sized buildings, which may suggest it's too modular.

[0]: [http://jdan.github.io/isomer/](http://jdan.github.io/isomer/)

<comment><USER5> As design patterns go, optimizing your code library so that it makes a more visually appealing virtual city seems like a bad one.

</comment></comment><comment><USER6> I wonder if it would be feasible to represent 'traffic' in a 3D code visualization city, representing data movement in a concurrent program. A 'car' would represent a function application such as a dynamic memory operation (there would be a heap building) or of a classes instance member, and it would transport function arguments/instructions/data from one building (class) to the next. Of course, just like in debugging, the only way to get traffic data would be to get a trace of a certain time period of a programs execution.

Of course in concurrent programming, data races can happen within these function applications as well. I can't think of a good way right now to visualize execution within in a function.

</comment><comment><USER7> Most software starts as a small shed, and ends up as a skyscraper... but with that shed still being the foundation of the scraper.

It would be nice if that could be visualized here :)

</comment><comment><USER8> Before I read the details I figured it was a picture of number lines committed per contributor. With tall monoliths being single contributor projects, and urban sprawls being multi committer projects. Now, I wonder what that visualization would look like for all these different projects.

</comment><comment><USER9> To push the metaphor further, one could animate the evolution of the buildings over time based on git history.

</comment><comment><USER10> Very interesting! JavaScript powering the visualization of JavaScript.

<comment><USER11> It's meta all the way down.

</comment></comment><comment><USER12> It would be cool to see a JSCity of JSCity itself on that page.

</comment><comment><USER13> aside from looking great - what does this tool give us?

<comment><USER14> A quick visual overview of how complex a codebase is

<comment><USER13> I cannot imagine someone on a dev meetup saying "we ended up choosing knockoutjs and backbone over angular because their models were more visually appealing than angular's city model" .. this is what I mean when I ask "what do I get out of this?"</comment></comment></comment>


Review my weekend HTML5 project: DropMocks - <AUTHOR> http://www.dropmocks.com/ I had an itch to scratch around making it easy to share sets of images with other designers and thought that I could use the new drag and drop file support to solve it. DropMocks was the result after a quick weekend of hacking.
It's built on an App Engine backend, and the uploader relies on the PushState and the File API from HTML5, so it only currently works in Chrome 6 and Firefox 4*; supporting other browsers would be the first post-hack step if I were to take it further.
An example gallery can be found here: http://www.dropmocks.com/mSER <comment><AUTHOR> I didn't realize submission text would be eaten for external links, so here it is:

I had an itch to scratch around making it easy to share sets of images with other designers and thought that I could use the new drag and drop file support to solve it. DropMocks was the result after a quick weekend of hacking.

It's built on a simple Python App Engine backend, and the uploader relies on the PushState, File, and FileReader APIs (I realize that some of these aren't strictly HTML5), so uploads currently only work in Chrome 6+ and Firefox 3.6+; supporting other browsers would be the first post-hack step if I were to take it further.

An example gallery can be found here, it should be viewable in all modern browsers: <http://www.dropmocks.com/mSER>

<comment><USER2> Zod approves: <http://www.dropmocks.com/mpUa>

Seriously, what a great project. If this is just a weekend project and a start for HTML5, I can't wait to see (and build) what's next.

<comment><USER3> Nice project. Sharing some great images here:

<http://www.dropmocks.com/mtfA>

</comment></comment></comment><comment><USER4> Why are you browser sniffing when you can easily do feature detection for the HTML5 File API (`"FileReader" in self`) and Drag and Drop API (`"ondrag" in document`)?

The only time browser sniffing is ever appropriate is when you _excluding_ a specific browser due to a bug, and there is no unobtrusive way to do so (e.g. a console.log bug that can't be tested without calling console.log() at least once).

<comment><AUTHOR> You're right - it would've been very easy to replace the browser detect with a feature detect once I knew what features I'd have settled on, at the time though compatibility was a distant second to proving the concept, so I lazily didn't bother.

I have spent many years of my life working on a browser that is frequently hurt by agent detection, so I'm well aware of the issues with the approach I took; and while I do think that there are a broad range of circumstances where it is appropriate, this is probably not one of them, so I accept your criticism and and pout into my bowl of ice-cream :)

Edit: I added your suggested code and am running through the tests now, thanks.

<comment><USER5> Also you may want to check out Modernizr if you are going to be bleeding edge:

<http://www.modernizr.com/>

</comment></comment></comment><comment><USER6> Wow, I have to say, that's pretty nice. It doesn't like me trying to drag images around that are already there. I expected it to let me re-order them.

But for a 'weekend' project, that's pretty impressive.

<comment><USER7> I was able to re-order mine. The UX isn't obvious that you can, but it works just the way I thought it would by drag-and-drop.

<comment><USER6> When I try to drag existing images, I get an error that (long string of characters) is not a valid image.

</comment></comment></comment><comment><USER8> didnt pass my browser sniffer, firefox 3.6 on ubuntu, but I know that supports drag and drop uploads, I wrote an image uploader the other week <http://dropup.net/>

<comment><AUTHOR> That's strange - my Firefox 3.6.6 on Ubuntu works with it OK. I wonder if the browser detect script I'm using is having issues, as another poster said that Chromium was failing, where it doesn't on my machines :\

Cool domain name; wish I'd thought of something that short.

</comment></comment><comment><USER9> I love this, the drag especially, i've never seen the "just drag" file upload thing before without flash/java. It'd be really nice to see a drag file upload replace the typical file form input.

Excellent job.

<comment><USER10> Gmail had it for almost a year.

<comment><USER11> Gmail uses Flash (Adblock shows block Flash thingie).

\----

Edit: upon further inspection, it seems Gmail indeed does use Flash [1], just for a different part of the upload process (progress bar?).

Drag and drop is only supported in Chrome and Firefox [2], so I suppose this is HTML5.

[1] <https://mail.google.com/mail/uploader/uploaderapi2.swf>

[2] [http://gmailblog.blogspot.com/2010/04/drag-and-drop- attachme...](http://gmailblog.blogspot.com/2010/04/drag-and-drop-attachments- onto-messages.html)

<comment><USER12> I don't think so. Maybe it falls back to flash on some browsers, but it works just fine on Chrome with flashblock enabled.

</comment></comment></comment></comment><comment><USER13> pretty slick :)

I created a client-side image shrinker - demo at <http://kimsal.com/shrinker> \- github at <http://github.com/mgkimsal/jsclientshrinker> Perhaps integrating this functionality for images that are 'too big' (whatever file size you decide) would be a nice enhancement? :)

<comment><USER14> definitely i'm gonna try your lib.

<comment><USER13> Cool. Fork on github and send any pull requests. The issues right now are that it only works with ff3 and chrome. I'd have thought safari would work, but it doesn't (didn't for me). Some integrated browser detection to offer transparent reduction for images on compatible browsers would great.

Let me know how it works out for you :)

<comment><USER15> I like how it changes the dimension. But converting to PNG is massively increasing the file size?

"Original file was: 137724 bytes Transmitted size was: 844176 bytes (due to base64) New file is: 633131 bytes"

<comment><USER13> It might be - not sure it's just a PNG issue, or if it's a canvas flaw, or what. The system could ideally check the before/after sizes, and only send the smaller one. Good catch (I think I'd seen that once in testing too).

</comment></comment></comment></comment></comment><comment><USER16> This is really wonderful. Our design studio is constantly posting PS comps for clients. We spend a significant amount of time outputting JPGs, building little galleries, loading the files to our servers, then sharing links to the designs via Basecamp.

Over the years we've come up with a few clever hacks to speed things up. For example, we keep our designs in svn and can quickly push updates live to our servers using a commit hook. But this is all sort of complicated, and I'd much rather use a web-app like this.

Dropmocks is very close to being the perfect tool for our workflow, and I suspect many other design/photo studios would feel the same way. A few features that folks like us would want/need: ability to pw protect galleries, ability to maintain revisions of designs, commenting (by both designer and client), and a way to export images to PDF.

Not sure if you'd target Dropmocks for businesses (such as ours), or if you'd like to have it open to the world and ad-supported. If the former, we're the kind of people that would sign up.

<comment><USER17> Dude - you could really check <http://disqourse.com> \- this app is to help you get customer ping-pong with mockups etc. easy.

</comment></comment><comment><USER18> Excellent work!

Suggestions:

\- tif not recognized as image, probably other formats as well (someone below said an image without an extension was rejected, maybe you need a smarter file rejection algorithm)

\- 900k is kinda small, maybe you should compress on-the-fly

\- UI needs work: I want to leave my mouse in one place and just keep clicking for more images (I know arrow keys work, and that's great, but consistency is key), no matter the size or where in the list I am (the ends of the list seem to break this pretty badly), image sizes shouldn't affect placement, jumping around the list is hard, maybe instead of or in addition to the "inline" list representation, you could have a scrolling or static list of thumbnails on top or bottom

\- the blur is too heavy. I already can't see much of the previous or next images because the one in front is too big, so why are they so occluded? Tone it down, maybe desaturate them a little too if you feel like less blur wouldn't take them enough out of the foreground

</comment><comment><USER19> I would love to see this integrated via an API into other sites, as it is definitely the fastest/cleanest image uploading & gallery I've seen to date. Some probably obvious suggestions: different views, display filesize/type info when mousing over an image, zoom in/zoom out, paid-users could have subdomains and gallery names instead of dropmocks.com/XXXX, etc. I envy your sweet design skills and attention to detail in the implementation (left/right/up/down keys work to go through the gallery, nice!). I would imagine you're aware, but be warned that trying to profitably monetize an image hosting site will be hard. Take a look into the guy who started imgur (mrgrim -- <http://www.reddit.com/user/MrGrim>) for useful insights on image hosting (assuming that's the route you're looking to take, and not a "YouTube Instant job offer").

</comment><comment><USER20> My favorite part is how well you scoped it for a w/e project and still came out w/ something useful. Very well done.

</comment><comment><USER21> I haven't said wow since Etherpad , I believe. Wow.

</comment><comment><USER22> I'm on mac chrome... uploading a hundred or so random pics i saved from reddit/digg... you are going to end up with the most bizarre collection of pics from everyone uploading their own strange test pictures. <http://www.dropmocks.com/m1e4> :)

<comment><USER22> Simple, works with all the pics even if the upload takes a while. How long until you run out of s3 storage or have to increase the size of your rackspace cloud server?

</comment></comment><comment><USER23> For those of you who are interested in a future-proof file drop plugin based on FileReader(), here you go:

<http://github.com/weixiyen/jquery-filedrop>

</comment><comment><USER24> Fucking brilliant! I'd love to hack on this... are you using app engine? Is it open source?

In particular, you know what would make this rock*10^6? facebook/dropbox integration.

<comment><AUTHOR> I would very much like to have this auto-pull from Dropbox folders; it is something for another weekend.

I just posted the source: <http://github.com/glenmurphy/dropmocks>

<comment><USER24> Auto-pull, auto-push, etc.

Also, to my phone. When I take a picture on my phone, I want it to sync to a dropbox folder.

Also, with facebook. I want each of my picture galleries to sync with a mock (and, optionally, to a dropbox).

Let's say a mock is synced with both dropbox and facebook. Then adding a file to the folder locally on a machine, it should push to mock, then from mock to facebook.

</comment></comment></comment><comment><USER25> Very nice visually, and _incredibly_ slick workflow, though it renders pretty slowly at full size. Poking in the code... are you blurring the images in JS at every level? Since you're using webkit + mozilla + IE specific CSS, why not use CSS transforms to do the same thing, but with hardware acceleration? I haven't done it myself, but I'd assume blur is one of the filters possible, and I know you can do those transitions.

edit: oh, and you might want to make sure the images in the "back" are (proportionally?) smaller than the ones in front - if you shrink your window a lot they're actually bigger.

edit 2:

Gets stuck occasionally, though so far only while loading, and doesn't seem to respond to any interaction. The drop-down still works though, so it appears it's not just spinning.

Anyone else, and/or any info I can provide to get you info on why?

<comment><AUTHOR> Blur is only possible in IE with filter:blur (and I use it if available) - I've been bugging people to add CSS blur to WebKit :)

<comment><USER25> Yeah, if it's not in there, it seems like a rather large oversight. Blur is _ridiculously_ frequently used, and it's so simple to implement.

In any case, gorgeous work :)

</comment></comment></comment><comment><USER26> How are you determining which browsers are compatible with it? It seems like the best way might be to use modernizr: <http://www.modernizr.com/>. Or are you using more than just the html5 drag and drop API?

<comment><USER26> Looking at the code you just posted it looks like this is what you did:

// HAMLET HAMLET HAMLET

function isValidBrowser() {

      var browser = BrowserDetect.browser;
      var version = BrowserDetect.version;

      return (
        (browser == 'Chrome' && version >= 6) ||
        (browser == 'Firefox' && version >= 3.6)
      );
    }

<comment><AUTHOR> Yep; I realize this is usually taken to be poor form, though I'm no idealist - I did it while the APIs I was using were in flux (I flipped through a few upload techniques), and focused on getting it working right in a few before expanding to the many.

<comment><USER26> Makes total sense. It looks great by the way.

</comment></comment></comment></comment><comment><USER27> I like this a lot. Works perfect in FF 3.6.3 (as it should) I too expected to be able to drag them around, It would be nice if I could just arrange them on the page like some of the css3 polaroid galleries you see. I will defiantly be using this.

</comment><comment><USER28> First off good job (love that people are using HTML5/CSS3). I checked out an album on my iPad since drag and drop is not supported :(. The transitions were very jerky. If you want to speed this up, switch from regular css3 transforms to transform3d. This is a less know fact that regular transforms are not hardware accelerated (iOS, as well as safari 5, tries to render a box that is hardware accelerated that the transform runs in which creates the jerk/flashing content), whereas translate3d is hardware accelerated for the full page. Mileage may very though since translate3d is very memory heavy.

</comment><comment><USER25> A thought, before this potentially spreads far and wide:

 _Should_ we be spreading this? Or might doing so tank your server / storage / bank account? Do you have any limits in place to protect you?

<comment><USER29> It is running on App Engine so to an extent it will be free. <http://dropmocks.appspot.com/>

</comment></comment><comment><USER30> Please add Safari 5 to the browser sniffer. (It works fine if I change the User-Agent to "Chrome 6", so presumably it should be included in the list of browsers that you support.)

<comment><AUTHOR> Safari 5, at least on Windows, doesn't support the File and FileReader APIs which are necessary for the drag and drop uploader. If you've seen otherwise, please let me know (I love the Safari team, and don't want to be unfair to them).

Nightly WebKit builds may work.

<comment><USER30> On the Mac, it works fine.

</comment></comment></comment><comment><USER31> What happens if this becomes wildly popular among casual computer users who want to share pics with their friends? Any plans on how to monetize it?

</comment><comment><USER32> I loved it. My only suggestion is making the non-focused images slightly opaque. I was left wondering if the severely blurred images were loading.

</comment><comment><USER33> Transitions are pretty jerky for me, but really great idea. Thanks for open sourcing the code, I'm excited to see where this goes!

</comment><comment><USER26> Did you consider using the new GAE API for image serving? I think it requires objects to be actual blobstore objects rather than in the datastore as a blob property, but it does dynamic image thumbnails. It does do dynamic resizing of picture to a bunch of different sizes, but requires a slightly different workflow to get pictures into the db.

</comment><comment><USER34> Never have I been so forehead-smacking jealous that I didn't think of something first. kudos.

</comment><comment><USER35> This is awesome stuff, great job.

However, I dragged an image ( but did not have any extension) - and it mentioned that the file is not an image.

I know this is a rare case ( heck what are the odds of me selecting me 1 pic which does not have an extension!) Anyways, good stuff.

</comment><comment><USER36> Doesn't work for me. I'm running Chrome 6.0 (beta). I also tried Firefox 3.6. In both cases I get a "browser not supported" message.

EDIT: Seems the issue has been resolved. It's working for me on both browsers now.

</comment><comment><USER37> Feature Request: Enable me to upload larger images that you could compress-on- the-go. It beats the entire simplicity of the system if I have to manually compress the images to upload them.

</comment><comment><USER38> I'm on Chrome 6 on Ubuntu. It's telling me that my browser isn't supported.

(Reason #101 why I hate browser sniffing, no one ever gets it right).

Beyond that, I wish you the best of luck, it sounds like something I can use.

</comment><comment><USER39> Simplicity wins. Very nice indeed.

Privacy can be an issue if the secret url leaks. Maybe a visit count/log (to detect leaks) and a (change) option (to get a new url and close the previous one).

</comment><comment><USER40> It has a client side memory/resource leak. After viewing some pictures, the browser takes several hundred megs.

Its listed under GPU Process in Chromium. I guess it is a Chromium problem.

</comment><comment><USER41> Well, this sucks. I'm not able to try it out, even with the latest version of Chrome. Any idea?

<http://i.imgur.com/ZYYUi.png>

<comment><AUTHOR> Please try again.

Cause: In order to make the open source distribution cleaner, I moved the app.yaml into the same directory as the other files. It was previously in the directory above, so my static_dir declaration went from source/files to ./files; the local App Engine development server handled the ./ notation fine, but the deployed one did not.

</comment></comment><comment><USER42> This is really cool, I dropped 66 images in there and it went very quickly...I'm always jealous of the Weekend project that some people pull off. Nicely done.

</comment><comment><USER43> You can forget about IE most of the time, but Safari and other version of FireFox makes it kinda hard. Good start and hope to see improvements...

</comment><comment><USER40> I am really impressed. Clean and simple to use. I can't believe that this is a weekend project.

I am currently studying your code. Thanks for making it available.

<comment><USER44> These kind of weekend projects make me feel insignificant. But then I see that author is on Chrome UI team so he is familiar with technology required (App Engine, Chrome HTML5).

Without that context it is just magic(and even then idea and implementation is great). But I think there must be something many of us can do in a weekend that will look like magic. But it was possible because of months/years of experience.

</comment></comment><comment><USER45> The images left and right of the current one distract from what should be the focus. Doesn't work well for sharing small image files.

</comment><comment><USER46> Awesome. Only comment I have is that some way to tell how many images there are and where you are in the sequence would be useful.

</comment><comment><USER47> Great idea and execution, definitely needs better security. I was able to find several other galleries just by poking urls

</comment><comment><USER48> Firefox 4b7pre is still loading up the image file after I dropped in on the page, so in fact it doesn't work at all.

</comment><comment><USER49> Very great! Love the easy way to use it without having to log in to try. Simple approach. Keep working on the idea.

</comment><comment><USER50> Amazing, great user experience. One detail though, wouldn't it be nice to have less blur on the thumbnails?

</comment><comment><USER51> Amazing idea and execution. Great work.

</comment><comment><USER52> Great Job.

Where to go from now, launching image service (flickr) or making this open source (e.g. light box) - up to you

</comment><comment><USER53> My pictures were too big. > 900k.

</comment><comment><USER54> Love the concept.

Your shadows look very odd with the very horizontal screenshots I dragged in to test it.

</comment><comment><USER55> Love it! Nice work.

What did you write it in?

</comment><comment><USER56> Like it because of simplicity, I like this more than flickr slideshow.

</comment><comment><USER57> Error: image exceeds 900KB

Having to resize images before the upload is a deal breaker.

</comment><comment><USER58> you should use the blobstore api to break the 1MB limit. Also check out the new high performance image serving service @ <http://j.mp/9UvNyZ>

cool project

</comment><comment><USER59> I'd like to see read only access on older browsers and the iPad.

</comment><comment><USER60> Great application!

Small feature request: link to particular image with #

</comment><comment><USER61> the biggest ideas are the smallest stuffs like that. This is deadly useful! Wish you good luck with this idea!

</comment><comment><USER62> Looks great

</comment><comment><USER63> This is really awesome!

</comment><comment><USER64> drag+drop not working on firefox 4. It does work with gmail.

</comment><comment><USER65> This is beautiful.

</comment><comment><USER66> Dude, that is sick

</comment><comment><USER67> hi i find it kind of slow...

</comment><comment><USER68> Weekend?

</comment><comment><USER69> I'd pay you $24 a year (what i currently give to flikr) if you can compress my large jpg images into something smaller (currently it seems to be maxed at 900k) another one of my favorite features of Flikr is the ability to view exif data.

Love the project!

<comment><AUTHOR> Would you be OK with resizing? App Engine has a 1MB limit, and I could get around that by splitting the file on the client, but I could also just do a resize in JS with canvas/ImageData.

<comment><USER70> You should probably be using the Blobstore API if you are not already.

[http://code.google.com/appengine/docs/python/blobstore/overv...](http://code.google.com/appengine/docs/python/blobstore/overview.html)

It takes a bit more work but you could store the original file since it has a 2GB limit. You can only fetch 1MB at a time but it should still be doable.

<comment><USER71> Another option is to use boto to pass the upload along to S3 and just store the link path in app engine.

</comment></comment></comment></comment><comment><USER72> does't work on 6.0.472.53 chrome.

<comment><USER72> using linux flavor - ubuntu 10.04

<comment><USER63> Also doesn't work for 6.0.472.59 beta on Ubuntu 10.04. I get the browsers detection error message.

Edit: Works now! Thanks.</comment></comment></comment>


The Big Word Project - Viral marketing campaign to redefine the dictionary - <AUTHOR> http://www.thebigwordproject.com/about <comment><USER2> Thanks for posting this, i just registered foo!</comment>


"Safe C++ Subset" Is Vapourware - <AUTHOR> http://robert.ocallahan.org/2016/06/safe-c-subset-is-vapourware.html <comment><USER3> Yes, Core C++ will never make C++ as safe as Rust.

However a programming language is just so much more than the language itself.

So until Rust can make up for the libraries, IDE integration, GUI libraries, ability to use COM and WinRT as if they C++ classes (C++/CX, C++ Builder, Delphi), mixed mode debugging like C++ has with JVM and .NET IDEs...

Many of us that need to stay in C++ land would rather have a bit of Rust security around our tools, than having to leave all that behind while Rust libraries continue to make use of Rust nightly just to get that tiny cool feature X.

If this isn't the case, it is how it looks form HN posts. Last case being one doing so for the Regexp macros, I just forgot the name.

I know how hard this is, after all I am part of C++ community since the C++ ARM was the only language standard available and used to be part of Turbo Pascal, Modula-2 and Oberon communities.

However, at least the C++ community is trying to make the language safer even if due to Rust's pressure.

Not like the C community that the best they have came up with was the optional Annex K (Bounds-checking interfaces), which doesn't offer any value. Pointers and lengths are still used separately anyway.

<comment><USER4> You are right. rust is lacking many many things. C++ will still be around in 30+ years. But remember, C++ has a good 10 year head start on java, and java gained a lot of traction because of all the tools they didn't have to build.

Nobody needs to build valgrind for rust (or your favorite alternative). Leveraging existing libraries isn't trivial, but it's not a year long project either. IDE's support a lot of languages out of the box. rust support will be rough at first, but quality will be proportional to use. I suspect microsoft could build the layers you want like they did with J++ very quickly. A year? maybe 2?

The biggest bottleneck, imho, is developers. I don't think many people really _know_ all the dark and scary corners of C++, but there are a ton of people that can get stuff done in C++.

If schools start graduating people with rust experience, the writing is on the wall for C++. Shifting school curriculum takes a big reason. Maybe a hit indie game, maybe some other killer app. I don't think servo is the one.

Really, it's a testament to the quality of the language that the complaints are all along the lines of "it's fantastic, but the tooling..." Don't underestimate that. Tooling can happen real fast.

Is rust a sure thing? no. absolutely not. does it have a chance of becoming _the_ systems programming language in 10 years? Yeah. i think it does. i think it's got better than a 5% chance of doing that. 1 in 20 is a perhaps an insanely high number. The language is just so very good.

<comment><USER5> >"But remember, C++ has a good 10 year head start on java, and java gained a lot of traction because of all the tools they didn't have to build"

The thing is... I don't think Java took over C++ developers. Most likely they took over Pascal, Delphi, VB, Perl and other enterprise developers.

Every decade there is a language that claims to kill C++ (Java in the 90's, Go in the 2000's) offering features that are not bothering C++ developers and end taking off by attracting developers from other communities (like Go with Python devs).

I believe that memory safety or manual memory management is not the mainly concern for a C++ developer. On the other hand, if you give the same tools that C++ has and reduce complexity and then you might got into something, until then...

<comment><USER6> You are forgetting that Enterprise WAS C++ before Java.

Amazon went from C++ (to Perl) to Java.

Google went from C++ to C++/Java (and now Python and then Go)

Microsoft went from C++ to C++/C# , C# is Microsoft flavor of Java.

<comment><USER7> In certain areas such as games, GPU, etc C++ still rules, which is why I restarted on c++ nowadays.

</comment></comment></comment></comment></comment><comment><USER8> I tend to agree. Fixing C++ memory safety without turning it into a different language is hopeless. It's been tried many times. I took a crack at it once. So did the Rust designers. There's a whole literature on this. You have to forbid too much.

Previous attempts include Microsoft source code annotation language (SAL), Cyclone (AT&T research language), SCC, the Safe C compiler, Ccured, and MemSafe. None really went anywhere.

What this probably means is another sort-of-safe dialect of C++, accompanied by hand-waving and PR.

C++ is trying to do single owner semantics, but without something like Rust's borrow checker, the best you can do is crash at runtime on violations of move semantics. You have to design the language around borrow checking to get ownership right.

Still, it's good that the C++ crowd is trying. A decade ago, I was trying to get the standards committee interested in memory safety issues, but they were into exciting new template features used by few.

<comment><USER9> You can add to this list strictly-restricted subsets of C++ used for kernel development because it just has to be sane. A notable example is Darwin and kexts. I don't know what the NT folks are using.

<comment><USER10> The idea that you can find a sane subset of C++ is itself insane.

<comment><USER11> Really?

[https://news.ycombinator.com/item?id=11895686](https://news.ycombinator.com/item?id=11895686)

<comment><USER10> From your linked post:

> > [https://www.cis.upenn.edu/~eir/papers/2013/ironclad/paper.pd...](https://www.cis.upenn.edu/~eir/papers/2013/ironclad/paper.pdf)

It still relies on dynamic checks. So you still have the same problem as in Java: just because you have a reference, it doesn't mean you actually have a valid object. You can make any language trivially safe by checking absolutely everything at runtime, but the whole point to using a language like C++ is to not incur in unnecessary performance overheads.

> [http://research.microsoft.com/en- > us/um/people/marron/selectp...](http://research.microsoft.com/en- > us/um/people/marron/selectpubs/Undangle.pdf)

Have you actually read the paper? This isn't a static analysis at all. It just makes a dynamic analysis more eager and precise.

<comment><USER11> Appreciate insight on first link. Far as other, that's my mistake given I only read parts on anslysis, diagnostic, and performance. It was in a list of static anslysis stuff I found. So, I wrongly assumed it was static analysis instead of verifying it myself as I did first one on that page [that worked but had limitations].

</comment></comment></comment></comment></comment></comment><comment><USER12> I've found that binding C++ to a scripting language makes a lot of sense when dealing with safety issues (and other problems).

While I have worked on plenty of C++ projects that had _sections_ with performance-critical code or frequently-allocated data structures that need careful control over memory, I have never seen an _entire_ program in this category. For that matter, I probably haven't seen one with more than 40-50% of the C++ code in this category. Invariably, you start to see people write painful code to do trivial-things-that-are-not-trivial-in-C++, intermixed with the things that might actually benefit from C++.

You can offload a _lot_ of less-critical C++ code, forcing it into a higher- level programming environment where fewer things can go wrong, in a language that is accessible to more programmers.

<comment><USER13> But which scripting language? C++ header are fairly hostile interfaces for wrapping. You end up with either tons of hand-written glue code or littering your header files with annotations so they can be sorta wrapped.

Python is not very good as an embedded language (globals and locks). Lua is OK but AFAIK making C++-like classes in Lua is a pain, and the language is a bit annoying for other reasons.

<comment><USER14> Which reasons?

<comment><USER13> IIRC, if you make a typo in a var name in Lua, you don't even get an exception like Python -- you just get nil. I'd prefer it to be more strict about errors like that.

1-based indexing. Prototypes rather than classes -- I don't think having to roll your own or research an object system for every project is a good use of time.

Lua is a great language implementation, but whenever I try to actually program in it, it feels like an inferior version of Python...

</comment></comment></comment></comment><comment><USER15> The other day I thought "I'm finally gonna dive deep into C++, and I'm going to start out right, with a mindset toward modern C++ and statically forbidding memory errors, etc."

First thing I did was write up a test program that looks something like this, to see what errors I would get:

int x = 42; int* px = &x; px++; *px = 12;

Compiled on GCC with -Wall. No warnings. I thought for sure some warning must prevent pointer arithmetic. After asking around I guess what I did above wasn't really pointer arithmetic, at least not in the compiler's eyes, so it's not warned against.

<comment><USER16> There are plenty more warnings to turn on than what -Wall uses.

[http://stackoverflow.com/questions/11714827/how-to-turn- on-l...](http://stackoverflow.com/questions/11714827/how-to-turn-on-literally- all-of-gccs-warnings)

<comment><USER15> unfortunately it passes -Weverything on clang, as well.

</comment></comment></comment><comment><USER11> It's not vapourware: it's called Ironclad C++ and it's on Github. :)

[https://www.cis.upenn.edu/~eir/papers/2013/ironclad/paper.pd...](https://www.cis.upenn.edu/~eir/papers/2013/ironclad/paper.pdf)

[https://github.com/crdelozier/ironclad/](https://github.com/crdelozier/ironclad/)

Rust still wins out against it. Yet, a C++ subset with type and memory safety capabilities does exist. The benchmarks look good with conservative GC and all checks on. I vote it as worth consideration for anyone trying to improve C++ app's safety. Might be worth FOSS types improving on if they're sticking with C++.

Edit: Removed link to tool tgat wasnt static. My mistake on that.

</comment><comment><USER10> Agreed wholeheartedly.

Take this blog post, replace "Lisp" with "C++", "Haskell" with "Rust", and "type system" with "lifetime system": [http://axisofeval.blogspot.com/2011/01/why-lisp-is-big- hack-...](http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-and- haskell-is.html).

"C++, as it stands, can't do any of that, and won't be able to do any of that. That's simply a fact. Why? Because it's coming at the problem from the wrong direction. Trying to graft an interesting lifetime system or verification onto C++ is simply too heroic and ill-specified a task. C++ starts with ultimate freedom/unsafety, and you can't constrain it. Rust starts with ultimate bondage/safety, and then, piece by piece, adds that freedom back. On a theoretically well-founded basis."

This summarizes C++'s safety woes.

<comment><USER17> The article you link starts with:

> 2013 Update: I was young and stupid when I wrote this.

<comment><USER10> Which doesn't detract from the fact that it's easier to carefully add freedoms to a safe language, than it is to constrain an unsafe language until it becomes safe.

<comment><USER18> Yes, but while easier it is also less useful -- since the unsafe language we're talking about has millions of users, billions of lines of codes, tons of libraries, huge support, hundreds of books, great tools, etc. The safe one, not so much.

So making the unsafe language safer (even if not completely) can have much bigger impact and to far more people than touting some perfectly safe little language.

<comment><USER10> > Yes, but while easier it is also less useful -- since the unsafe language > we're talking about has millions of users, billions of lines of codes, tons > of libraries, huge support, hundreds of books, great tools, etc. The safe > one, not so much.

Is this a plea for sticking to broken technologies 'cause social/environmental reasons?

<comment><USER18> No, it's those things called "opportunity cost", "pragmatism" and "ecosystem"...

</comment></comment></comment></comment></comment></comment><comment><USER19> I would question if 100% memory safety is a goal worth achieving in itself. Everything comes with a price. At some point, making memory management more safe starts to come with some trade offs, performance, code flexibility and others. Sometimes "good enough" is actually good enough.

Why C++ will probably not be changed by other languages is the freedom it provides. It is a language equivalent of giving you absolute power of everything, including digging a massive hole, falling into it and not being able to crawl back out.

Yes, Rust is safer in and of itself, and "encourages" safety, but it is also like riding a bike with a safety wheels and cushions strapped everywhere. At some point it will start just getting in your way more than helping you.

In the end it boils down to purity and elegance vs. efficiency and practicality. And I'm bigger fan of efficiency and practicality than purity and elegance.

<comment><USER20> Those are some nice metaphors, but what would a concrete example be, where you absolutely need unsafe memory operations to archieve certain performance levels?

("Need" meaning "it's fundamentally impossible to do it safely", not just "the language provides no way to do this")

<comment><USER21> There is no such thing as "fundamentally impossible to do it safely": if you use a theorem prover like Coq then you can formally verify _any_ * code as correct, not just memory safe but truly bug free. See seL4. You'll have to write like 20 lines of proof code for every line of real code, and that code is difficult to write... but it's possible.

On the other end of the scale, Rust doesn't have much annotation overhead, but if you truly want zero cost, the borrow checker has significant limitations - you can't have any cycles in your ownership graph, not even parent pointers. The alternative is to live with reference counting overhead, and I'm not sure how much benchmarking has been done of exactly how much overhead that is, but the community tends to value pragmatism over purity, so a lot of data structure libraries take the third option and use `unsafe` fairly liberally behind the scenes. (Which makes the parent's point somewhat inaccurate - <USER2> is _not_ pure 100% memory safety; unfastening the seatbelt is possible. You just have to explicitly request it.)

Of course, there is a huge gulf between those two paradigms. There are languages out there that could be said to live somewhere in the middle, like ATS, but they're not popular, and in general I think the spectrum is quite poorly explored. Certainly in theory there should be a fair amount of room to build from Rust's pragmatic approach and improve on it, by expanding what kinds of ownership models can be checked and/or reducing annotation overhead - but so far nobody has figured out what such an improvement could actually look like (except maybe this C++ thing, if it's not vaporware, heh), so it's up in the air how far this can be taken. I expect and hope Rust itself will continue to improve.

* Technically not _any_ , due to Gödel's incompleteness theorem, but certainly any code a human would write. (Anyone who cites either the incompleteness theorem or the halting problem as having practical relevance to basically anything in computing is mistaken.)

<comment><USER22> > * Technically not any, due to Gödel's incompleteness theorem

Sorry, but it's not true, see Gödel's _completeness_ theorem. It basically states that any "true" statement is provable. So you can verify any correct code as correct. There are problems if you try to verify a not correct code as correct though.

<comment><USER23> Godel's completeness theorem applies to first-order predicate logic, which is not powerful enough on its own even to _express_ , let alone _prove_ , 1+1=2. First order logic is best thought of as a framework on which other, useful logics may be built. And as soon as you add enough power to first-order-logic to capture Peano arithmetic, you run into incompleteness.

C++ behavior is almost certainly more complex than Peano arithmetic.

</comment></comment></comment></comment></comment><comment><USER24> Rust is better than C++</comment>


Open source software for developing world hospitals - <AUTHOR> http://hospitalrun.io/ <comment><USER2> Sorry another story about my journey with my son while he battled cancer.

Closed Proprietary image formats and systems HURTS patients. We used the local hospital for Chemo and everything else at the Children's Hospital 1.5 hours away for his legs and lungs. I would always have to wait 20-30 minutes to get a DVD of the studies (PET, CT Scan or MRI even ultrasound, but those are worthless) and then bring them to the doctor. The doctor would be forced to use whatever the portable image viewing program that came on the DVD and then they had to be sent to the IT Department to be imported into their system.

We would be there to remove some horrible tumor but before half his surgeries (I can't count how many surgeries he had) we would have to go in the day before (3 hour round trip) to get the expensive scan done again. One time I had a scan at 11 PM - Midnight and then drive home around 2 AM and be back at the hospital at 7 AM check in for a 10 hour surgery. ALL BECAUSE THE FORMATS ARE CLOSED and SYSTEMS could not connect so that my son's records were all the same every where. I carried 20 DVDs with me all the time just in case.

In case you are wondering my son unfortunately passed away after almost 5 years of fighting. If you are ever interested in giving to a cancer society please consider stbaldricks.org. Most charities give 0% or 2% to pediatric research and that is why we went over 20 years without a new chemo for children till last year, which St Baldrick's funded the research for this amazing new drug to fight a different type of cancer my son did not have.

<comment><USER3> I'm shocked and also confused in reading this.

Why? Because the standards are there!

The ACR/NEMA standard dates back to 1985(!) and is nowadays known as DICOM. Here in Germany/Europe, the medical imaging systems as well as the archive systems (PACS) are designed to follow that standard. DICOM covers everything, from the exact flavour of lossless(!) image compression, to the metadata structure which covers fiels more than you ever need to describe the patient, up to the archiving of data. There are even Free Software / Open Source clients which do a great job in visualizing those datasets (OsiriX is a well known example).

I thought that this is an international standard. How can any hospital afford to buy crap medical devices that don't care about such an important 30-year old standard?

Did I get something wrong about DICOM?

<comment><USER4> Until the early 2000s, DICOM was often an expensive option. Especially in "single vendor" shops where all hardware was from $VENDOR. BTW, the euro player were also fond of this.

Even with DICOM, not all encodings (either low-level, like value representations, or high-level like transfer syntaxes and image compression algorithms) are supported by all viewers/PACS.

Finally, every system assign patients their own local ID and does their own local numbering/coding for precedure IDs and so on. This adds delays and work when loading foreign images into a PACS.

I won't get into the bugs. I work in the field and I've seen some low-level DICOM handling functions riddled with quirks, exceptions and work-arounds for buggy imaging machines. With all that, we still see images that are utterly broken and only openable in the original system.

When doing the transfer over a network, it's often possible to negotiate down to explicit VR and Big-Endian uncompressed images which is required to be implemented and gets workable (if large, 500+MB for CT) images. With a CD/DVD, you're at the mercy of whatever syntax the creating device felt like using.

If you include PET and similar, then you also need proprietary PET/CT or PET/MR fusion software to actually make use of the images.

</comment></comment></comment><comment><USER5> That reminded me about story my friend told me some time ago. He's IT specialist in hospital, they were having some problems with x-ray machine with server based on windows XP and thin clients as viewing stations. Eventually it was replaced with debian based workstations and haven't look back ever since. After this he told me about interesting case with it, there was patient complaining about middle foot pains, on previous setup x-ray photos showed nothing, after switching to debian workstations they were using aeskulap dicom viever ([http://aeskulap.nongnu.org/index.html](http://aeskulap.nongnu.org/index.html)) which had more adjustments for viewing those files, like hue, saturation, color and so on, so after opening those photos with aeskulap and fiddling a bit with parameters it clearly showed that patient has broken bone in foot but in unweighted position it was almost invisible line on black and white default viewer.

<comment><USER6> Stuff like this shows the gulf between research and clinical practice. I'm doing a PhD in medical imaging, and we have carte blanche to run whatever we want. We generate a lot of amazing visualisations.

But almost all hospitals are stuck running out-of-date software that wasn't even good when it was released.

<comment><USER7> How does a healthcare system or private clinic acquire such software? What is the solution? Are the bottlenecks monetary, political, access?

<comment><USER6> Good questions, and I don't claim to fully know the answers.

Some such software is released open-source, e.g. NifTK, FSL, MedINRIA. Some is spun out and then sold through vendors as a service, e.g. Siemens, icoMetrix, many others.

Why aren't things used more? I'd say the main bottlenecks are monetary, political and cultural. Doctors are often set in their ways, and hospital management staff are risk-averse. Moreover, because of legal liability issues, a lot of this stuff has not been formally approved for clinical use -- so hospitals won't touch it. This is especially true of the open-source software. Getting approved is an expensive and time-consuming process. Service contracts with approved software are expensive, mostly as a result of this.

Heck, look at the struggle involved in digital patient records, which is supposedly a simpler problem than imaging. In the UK, we've spent billions on that without getting anything usable. There are uniquely bad political reasons for that, but it's illustrative nonetheless.

</comment></comment></comment></comment><comment><USER8> I've been volunteering in hospitals in a developing country for a while now and the information systems they use here are really bad.

With an eye on replacing said information systems, I've had a look at the open source medical records / hospital management systems available. When I looked at the details these systems are often not great replacements. So you're replacing aging, poorly written information systems with aging / non user friendly / difficult to customise information systems.

I would like to suggest some things for you guys:

1\. Instead of creating one large hospital management system from scratch, how about smaller systems that can be linked together? eg. patient records system / laboratory system / pharmacy dispensing system / billing system / etc. The systems I mention here have fairly minimal dependencies between each other. This gives you the time to create a best of breed system before moving onto other stuff. It also allows hospitals to be able to use your stuff without ripping out everything they already have!

2\. Think about how a hospital would customise your system. New fields, forms, reports, workflows, logic, etc. And how these customisations would survive an upgrade of the core system.

Anyway, I hope you have success with the project and I wish you luck. I'll definitely be keeping an eye on it!

<comment><USER9> This comment should be at the top. I love what this project is aiming to accomplish but also think that the task is gargantuan and the project's users would be better served if it was divided into independent modules.

</comment></comment><comment><USER10> [https://en.wikipedia.org/wiki/List_of_open- source_health_sof...](https://en.wikipedia.org/wiki/List_of_open- source_health_software)

Please avoid too much diversification by reinventing wheels, instead please contribute to one of these projects.

Mobile first is a basic requirement in developing countries.

<comment><USER11> >Mobile first is a basic requirement in developing countries.

When you say "mobile first is a basic requirement" you're thinking about a specific context of software intended for the general population of people in those countries.

However, with projects like HospitalRun, the general population is not the audience, Hospital staff and administrators are, and even in developing countries they still primarily use laptops and tablets at the Hospital.

<comment><USER12> Agreed. For them, offline-first is very likely to be more important.

</comment></comment></comment><comment><USER13> Looks great. Why such emphasis on "Ember"? Does the target audience really care what front-end framework is used?

<comment><USER14> I applaud the efforts taken here, more than I've ever done, and it looks good. But wasn't there big talk of Ember's (JavaScript's) poor(er) performance on Android devices recently? It seems like this tech would be prime for Android users. I don't know if the performance is bad from a usability standpoint or just a pure numbers via specs point of view.

<comment><USER15> Ember is an excellent choice for offline-first mobile applications, like this one, because Ember can manage more on the client side.

You're likely recalling the recent article on HN that showed Ember taking longer to download the first time vs. React on a mobile phone.

In a third-world offline hospital records app, the first time difference isn't especially important, and also it's more likely the hospital record keepers will use tablets, not phones.

</comment></comment></comment><comment><USER16> This is a great initiative, I logged in the beta and tried a few things, which mostly worked, although somewhat slow. Probably a lot of hospital administrators active now :-)

What surprised me most is that the UI does not seem to be mobile responsive, and does not work well on smartphones. I would have guessed that in developing countries mobile use would be hugely important?

<comment><USER17> Are they likely to have smart-phones to use?

<comment><USER18> I just spent a week in La Gonave, Haiti. Everybody had smart phones...which was particularly impressive because electricity is hard to come by.

<comment><USER19> That's precisely why - You don't need 5 hours of electricity to get 5 hours of use on your smartphone, but you do need constant juice for a desktop PC.

A laptop would also give you more time, but not as much as a smartphone.

</comment></comment></comment></comment><comment><USER20> How does this compare to OpenMRS? Hospitals because they have to obey a lot of goverment regulations needs to customize a lot of things, records and reporting so we did a lot of work around the plugin architecture in OpenMRS, does this have similar extension mechanisms too?

</comment><comment><USER21> I'd be very, very happy to contribute to this.

It seems you have a nice focus in usability - efficacy, efficiency and satisfaction. For me, it seems vital to make IT useful and not a burden, reducing clinicians wasted time on non-clinical duties and their general _distaste_ with the software they have to use. I'm a UX PhD, I have experience working with very particular groups of users, and I would be very motivated in working for better healthcare.

<comment><USER22> Amen. As a doctor I have to deal with a lot of crappy computer interfaces. Data entry in hospitals (at least the sort that gets the hospitals money) ends up being done by non-medical personnel because the medical personnel are too busy trying to do their job to care whether they coded something wrong on the computer system.

</comment></comment><comment><USER23> At quick glance this seems to be fantastic! Software like this is what brings out the great nature of open source. This project reminds me of the eye tracking system that gained popularity a few weeks ago.

EDIT: Here's a link to the referred to project [https://github.com/OptiKey/OptiKey/wiki](https://github.com/OptiKey/OptiKey/wiki)

<comment><USER24> That was the first thing that came to my mind after reading this. I was at reddit when the author of OptiKey posted it, the responses were amazing.

</comment></comment><comment><USER25> While I don't agree with many of the specifics of the HL7 spec[1], I guess the community behind this project should decide if this system will conform or not.

[1] [http://www.hl7.org/implement/standards/](http://www.hl7.org/implement/standards/)

<comment><USER26> IMHO, the HL7 specification isn't particularly strong. Different vendors support different message types, some vendors fill in this field, some another. Most of the work I did with HL7 was making sure System A could read the messages we were passing it from System B by "translating" the HL7 messages.

That said, there are open HL7 message "interface engines" and integrating with something like Mirth[0] shouldn't be too difficult.

[0] [https://www.mirth.com/Products-and-Services/Mirth- Connect](https://www.mirth.com/Products-and-Services/Mirth-Connect)

</comment></comment><comment><USER27> I can't seem to login, I enter the doctor username and password press submit and it refreshes the page and nothing shows.

<comment><USER28> Same here - suspected a problem with my iOS content blocker, but that doesn't seem to be the case.

</comment></comment><comment><USER29> Imagine if this got better than systems that are on offer when this requirement goes out to tender for the NHS institutes in the UK?

So long as it doesn't do over night batching, it's already decades ahead. I wish I was joking.

<comment><USER30> Is it one of these things, that there are so many edge cases, regulations, domain knowledge involved that makes it perceived as too big to change?

Because I'd believe that you can't just make something that looks better and sell like you'd sell a typical SaaS product, there must be tons of regulations.

On other hand, while studying in the UK, I briefly met a PhD student who was making offline-first web apps to calculate the dosage of the medicine etc and hospitals in the UK where actually using them (and paying him to develop).

<comment><USER31> A huge amount of the work is just making the software work for any given workflow or organizational structure. For perspective, Epic has a couple dozen people working full time on just the user management parts of their software.

</comment></comment></comment><comment><USER32> They should look into these technologies to better protect patients data:

[http://research.microsoft.com/pubs/258435/ManualHE.pdf](http://research.microsoft.com/pubs/258435/ManualHE.pdf)

[https://css.csail.mit.edu/cryptdb/](https://css.csail.mit.edu/cryptdb/)

[https://css.csail.mit.edu/mylar/](https://css.csail.mit.edu/mylar/)

</comment><comment><USER33> I worked in this space for a very long time. Here are my thoughts on health data integration [0]. In a nutshell:

"At it's core the government need only do one thing to encourage innovation in the interoperability space and it is this:

The government, by means of regulation and incentive, ensure that any vendor of data systems that create or store data make adequate interoperability features and documentation available for said system.

I call this the Core Mandate. The core mandate must be unequivocal with no loopholes. What do I mean by "interoperability features"? Simply:

\- If a system creates data, the ability to read that data is fully described in documentation.

\- If a system stores data, the vendor will provide an API and/or SDK, with accompanying documentation, such that authenticated requests may create, read, update or delete that data programmatically as appropriate.

A system is defined as any software application or hardware device."

[0] [http://siculars.posthaven.com/health-data-integration- regula...](http://siculars.posthaven.com/health-data-integration-regulation- and-incentivization)

</comment><comment><USER34> Ohh wow this looks very nice. Unfortunately I can't login for some reason.

So I am actually finishing the development of a similar system for a group of anesthesiologists that needed a custom app to keep track of their patients and their pain medication.

Had I known of this project before I would have actually considered contributing/forking it to handle their use cases. See this hits pretty close home since I'm Colombian and hospitals here have terribly outdated systems.

I love the idea of the app working offline and syncing when internet is available since mobile networks here aren't verye reliable. One problem is,as others have mentioned, having it work on mobile is very important. I don't think it really is because of lack of PCs and desktops it's just that doctors are always running all over the place and it's more convienent for them to log the information on a smartphone/tablet.

Anyways my next project is also on the medical field and will have a wider scope so I'll keep an eye on this project for when the time comes, I'd love to contribute eventually.

</comment><comment><AUTHOR> Quite proud to see PouchDB being used for things like this, it looks like pretty much a perfect use case.

</comment><comment><USER35> Nice project... here are my observations thus far

      - login screen takes several seconds to load
      - not usable on screens/mobile devices
      - seems like every click makes multiple server requests
        (and loads for up to several seconds)

Also, would like to hear your thoughts on building a new system vs building on top of the many available open source medical systems.

<comment><USER11> Responsive work is on the roadmap and coming soon. However, the current intent is for the project to be fully usable on tablets, but not necessarily on phones. The hospital staff in our use cases will all be using the software from either a laptop or tablet.

<comment><USER35> Understood. I'm on a laptop, and unless the window is full screen the UI isn't great.

<comment><USER11> Yeah, that's a fair criticism. Still a lot of work left to do on that effort.

</comment></comment></comment></comment><comment><USER36> Great effort. A similar open source campaign is being run under OpenMRS, called Bahmni ([http://www.bahmni.org/](http://www.bahmni.org/))

</comment><comment><USER37> I like the "Why HospitalRun?" at the bottom of the link...

[https://docs.google.com/document/d/1OhlxZY__spF_3ZnXLd5ga9vO...](https://docs.google.com/document/d/1OhlxZY__spF_3ZnXLd5ga9vOdX9xNqHGUASdVxAdLLc/preview#)

</comment><comment><USER38> I'm not in this area, so I don't know much about it, but can anyone compare this with GNUHealth[0]? At first glance, they seem to be trying to do many of the same things.

[0] [http://health.gnu.org/](http://health.gnu.org/)

</comment><comment><USER39> First off, I would like to say this is exactly the kind of thing that has the potential to have a monumental impact on global healthcare, not just in the developing world. We could definitely do with this type of initiative in the UK.

The reality is that some of the biggest vendors (US and UK based) actually ship some of the worst software and charge hundreds of millions of pounds for it. Ultimately, its the patients that pay the price. It's a complete myth that bigger vendors build safer systems.

I agree with a previous poster in that given more visibility, I'm sure there are thousands of developers that would love to contribute to this type of project (myself included).

It's also pretty clear that mobile will be a key requirement for this type of solution. Not just a responsive website but full native implementations. I realise that this can be expensive, but if it's open source, I'm sure there are developers that would love to get involved. Maybe you would consider an API? This might encourage an ecosystem of client solutions to flourish.

Finally, do you think there is a role for a patient login here? There is a world-wide movement to encourage patients to play a more active role in managing their healthcare and giving patients mobile access to their health records is a great first step towards this.

</comment><comment><USER40> Anyone else remember this CVE? Open (eg: passwordless) telnet on a blood infuser.

[http://webcache.googleusercontent.com/search?q=cache:3ygj10u...](http://webcache.googleusercontent.com/search?q=cache:3ygj10uTWqYJ:https://web.nvd.nist.gov/view/vuln/detail%3FvulnId%3DCVE-2015-3459+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER41> This is great. I recently had to create a prototype application for a charity with offices in a developing country and this would have been a perfect fit. I don't have access to GitHub at the moment but I wonder how far along their implementation of the 'off-line first' sync mechanism is, this is a non- trivial thing to implement.

I had a quick look at the demo and it looks like the development is in the early stages- a bit of (hopefully constructive) feedback: I think they (you?) may be trying to attempt to do (and cover) too many clinical disciplines at the same time- maybe implement individual modules (like patient registration) and test them in all (old!) browsers in more detail before moving on to the next. Also think long and hard about how you implement your data model (clinical indicators e.g. blood pressure often have a context and are temporal values, how do you model these?). This is a great effort and has lots of potential.

EDIT: also, the name seems to suggest to me like there is a run on hospitals- but that may be a personal thing.

<comment><AUTHOR> > I wonder how far along their implementation of the 'off-line first' sync > mechanism is, this is a non-trivial thing to implement.

The are using PouchDB + CouchDB for offline first / syncing which is how I came to notice it (I am a maintainer for PouchDB). So their ability to sync should be reliable and well tested and if not then its bugs for us to fix :)

<comment><USER42> We recently used Kobo Toolbox ([http://www.kobotoolbox.org](http://www.kobotoolbox.org)) for a health related survey in a developing country... The Ministry of Health required the data stored locally to be encrypted on the device and during sync (not just over https), which caused some problems for deployment. That will be an absolute requirement from any gov that looks to adopt the tech. Not sure if it was a PouchDB or Kobo shortcoming.

<comment><AUTHOR> I am not certain Kobo uses PouchDB, I dont remember seeing them mentioned, but its certainly possible to encrypt data that is synced with Pouch/CouchDB. Heres 2 projects (both written by Pouch maintainers) to help do that.

[https://github.com/calvinmetcalf/crypto- pouch](https://github.com/calvinmetcalf/crypto-pouch) [https://github.com/nolanlawson/transform- pouch](https://github.com/nolanlawson/transform-pouch)

</comment></comment></comment></comment><comment><USER43> While this is a good idea, how are the health compliance requirements enforced?

<comment><USER44> I'm struggling to understand the question - by testing for compliance like other software?

I'm assuming there'd need to be a services business installing and maintaining the software, and adding improvements particular customers need.

<comment><USER45> > I'm struggling to understand the question - by testing for compliance like > other software?

Medical software is a different beast, compared to, say, your next online shop or bloggin plattform.

Bugs in medical software can (and will) kill people. My work takes me to medical software development courses on a regular base and they usually consist of looking at the ways, medical software can kill people; sadly often enough by example.

One case for example was a PACS system where due to a bug in the way the database managed timestamps only the very first of a series of pictures was shown to the user. And since once could not navigate the pictures via "previous" and "next", but one always had to go through a purely text based menu (this was in the mid 1990-ies, where memory was scarse) it was not immediately apparent that only the first image in a time series was shown. Enter the patient with a tumor; when it was finally realized the images the medtech took were not the same the specialist saw it was already too late for the patient and tumor growth progression too far advanced.

So your medical database software kills someone (prescription error due to wrong dataset shown or such), how do you determine whose liability it is/was? Medical software certification is in large part about identifying what harms to a patient could be done and which parts of the software may cause it. You don't even rule out in a "this can't happen" way, but it goes like:

\- patient dies: no matter how well it was tested, these are the possible offenders in the program \- patient gets seriously harmed: no matter how well it was tested, these are the possible offenders in the program \- patient gets injured: no matter how well it was tested, these are the possible offenders in the program

The bottom line is you're ending up with something that is either close to or outright is waterfall.

And even more important: These are the components a program uses, what possible failure modes are there that could harm patients. So they're using CouchDB? Well, is CouchDB medically certified (AFAIK not), so this is considered SOUP (Software Of Unknown Pedigree) which means that to legally use this in medical applications you have to certify the SOUP yourself.

Oh and putting medical records into the Cloud? What could possibly go wrong…

<comment><USER46> From my perspective, this is not "don't use FOSS in medical situations" but "ensure the SDLC and code base meet requirements"

Unless we are talking foolish regulation, FOSS backed by taxpayer development money is likely to produce better and more open, transparent and testable code than proprietary companies competing against each other.

Government regulation perhaps should focus on building automated test suites as a first high level bar.

</comment></comment></comment></comment><comment><USER47> A somewhat related commentary article on why electronic health records (EHR) are difficult to work with: they are focused on billing not patient care. Doctors would prefer a care-oriented system. This could be a great inroad for open source.

<comment><USER47> Now with actual link: [http://www.cio.com/article/3011576/ehr/why-electronic- health...](http://www.cio.com/article/3011576/ehr/why-electronic-health- records-arent-more-usable.html)

</comment></comment><comment><USER48> Looks like it's way more open source than the two "open source" school MIS systems I looked at, one had no code available, the other an old version dumped on github, but not linked from their main page until you signed up.

<comment><USER49> Could you link to them please as I work at an MIS company that moved from open to closed source and wondering if our old codebase is still out there.

This project looks good, but it does remind me of the issues with management systems for public services. With the level of requests we deal with from school users that "need" features to satisfy management/governors/government it makes it very hard to do open source and be suitable.

<comment><USER50> You seem not to understand what open source means. Code released to the public under common free open source licenses mean someone can fork the code and put it on Github any time. If the company chooses to close source further development, then it's their unfortunate choice, nevertheless already released older open sourced code will stay open source.

<comment><USER49> Ahh, you misunderstood me. It was open source many years ago and that body of code doesn't seem to exist anywhere now.

Things have long moved on from that period, but a few of us are just curious to see if the code is still around from that time or if our product is one mavhc was talking about (unlikely).

</comment></comment></comment></comment><comment><USER51> This is a great initiative and I hope entire world adopts to such open standards for patient record management which can be freely transferable to other hospitals/doctors when needed or when approved by patients.

</comment><comment><USER52> Just after a first glance this looks really interesting! Brilliant idea.

</comment><comment><USER53> Anybody remember Care2x ?

</comment><comment><USER54> Why is it so similar to codio.com homepage?

<comment><USER11> Because design patterns, basically. I designed this page and have never seen codio.com before so I'd say it's just a reflection of common design paradigms for marketing pages.

</comment></comment><comment><USER55> This can only be done in developing markets because the health privacy regulations and mandatory screening laws cripple the ability of the Western medical industry to adopt open source solutions.</comment>


Show HN: Machinomy, JavaScript library for micropayments in Ether over HTTP - <AUTHOR> http://machinomy.com <comment><AUTHOR> Hi, HN, basically a one-man show here. Machinomy just turned v0.1, and I thought it could be a nice opportunity for feedback. Ultimate motivation for the project is to allow autonomous devices pay for themselves. This involves many things. The library is a prototype for the payments layer.

Some links:

[1] Project website: [http://machinomy.com](http://machinomy.com)

[2] Code: [https://github.com/machinomy/machinomy](https://github.com/machinomy/machinomy)

[3] NPM: [https://www.npmjs.com/package/machinomy](https://www.npmjs.com/package/machinomy)

[4] Gitter Chat: [https://gitter.im/machinomy/machinomy](https://gitter.im/machinomy/machinomy)

[5] Twitter: [https://twitter.com/machinomy](https://twitter.com/machinomy)

</comment><comment><USER2> Hey! Very interesting work. I left a question below (above?).

I myself have been hacking on a payment related project which is also in "show" right now: [https://news.ycombinator.com/item?id=13446587](https://news.ycombinator.com/item?id=13446587)

Would love to get your feels as you've been thinking about machine-machine transactions quite a lot obviously.

Happy to discuss more over email as well.

</comment><comment><USER3> You should simplify what this is about. I'm having g a hard time following all of it.

<comment><AUTHOR> This is a Node.js library that allows you to instantly* send a fraction of Ether as a payment for a HTTP service.

* - ok, if you have a payment channel open. A payment channel is an instance of state channels described on [http://www.jeffcoleman.ca/state-channels/](http://www.jeffcoleman.ca/state-channels/)

It allows you to pay for just one SMS sent instead of having a minimal credit on Twilio, as an example.

<comment><USER2> Is there a cost to setting up a channel?

<comment><AUTHOR> Yes, it is about 20 cents to open a channel, and 30 cents to close it.</comment></comment></comment></comment>