ndj7

What's the best way to teach modern C++ as a first programming language?

I'm at CU Boulder and their curriculum is outdated (90s) and backwards. What resources could I point the professors towards?

Looks like https://www.kickstarter.com/projects/njones/imageflow-respec... spurred them into action by offering the same thing, but without the proprietary, permanent lock-in factor.

Imagine the response were some terrible person to edit https://en.wikipedia.org/wiki/List_of_countries_by_GDP_(nomi...

It's clear we can improve our messaging about ways to integrate Imageflow. The command-line tool aspect is under-emphasized, and the libimageflow aspect seems to be confusing as well. What other things are unclear initially (or are still confusing)?

> but you definitely don't want this public web facing.

That's what dynamic imaging is. Your server generates images as needed, at the right size, in the right format. Even Kickstarter does this, although they use an extremely expensive and proprietary SaaS to do it. Nearly all e-commerce and CMS providers offer this, as do many CDNs.

We're making it free.

> imagemagick is used because it is binary library used on the backend

We don't use imagemagick; we own the entire rendering stack, thus the performance.

> now if this was a dropin library

libimageflow is a drop-in library. It's the focus. Any FFI-capable language can use it. Basic bindings take 5-8 hours to develop.

> and command line compatible

imageflow-tool will expose libimageflow's full power via the JSON interface. (There is also a simpler thumbnailing/converting tool following unix design practices, a prototype of which you can access immediately).

> adoption would be 100%

That's the goal ;)

This is not a hosted service, but rather a reusable library, server, and command-line tool.

Backers can already download a prototype of the command-line tool. We don't advertise it, because it's a less common usage scenario.

libimageflow is a C-compatible library you can use from any language, so there's no limitation on usage scenarios.

Imageflow has two parts - libimageflow, and imageflow-server. Both the library and server offer a JSON API, so it can evolve without breaking changes.

Most users leverage the Dynamic Imaging aspect - you store a single source file in blob storage, then dynamically generate variants as needed. This is like Scene7 or Cloudinary, but open-source, and at 1/1,000th of the cost.

Actually, the image rendering parts are far less difficult than the codec parts. You need the whole system in an operation graph in order to do the right thing to every image. Also, GIMP's scaling is still completely wrong - something I'm ashamed I haven't fixed yet.

We started Imageflow (https://www.imageflow.io ) in C to design the C ABI for interop with all the host languages, but we're swapping out components for Rust every time it's possible/practical.

There's a crucial difference; OpenSSL was designed to be secure. ImageMagick was designed to support hundreds of codecs and thousands of operations.

You can't pivot design on 1.25 million lines of code (est.) very quickly after 25 years of feature-first development process.

I'm a bit skeptical it will happen at all; it would be a multi-million dollar undertaking. Better to describe its design scope and tradeoffs, and get people to use it properly - sandbox it if it's on the server.

I started Imageflow to solve that problem - a server-focused design with strict design rules: security is first, followed by visual quality, followed by performance. We've kept the codebase to just 10kloc and we are 50% feature complete, but need to get a lot more momentum on Kickstarter to make completion possible. See https://www.imageflow.io

OSS also empowers individuals to create great things - despite limited financial resources.

We've been doing this for years; it's built into many on-demand asset pipelines, like ImageResizer: http://imageresizing.net/plugins/faces