Hacker News clone for Singapore - <AUTHOR> http://sigint.sg

<comment><USER2> One suggestion I have is to reduce the number of links on the frontpage to say 15 instead of 30 until there's a little more traffic on the site.

On the whole, great effort! Look forward to participating.

<comment><AUTHOR> Ok good suggestion. I'll dig around the code to change that when the traffic dies down.

<comment><USER3> Check out <http://newmogul.com/> and see how any article with comments has the comment count emboldened.

</comment></comment></comment><comment><USER4> What is the benefit of a region-specific version of Hacker News, especially one that is also in English? Most of what's discussed on this site is relevant to tech and the business of tech in general.

<comment><AUTHOR> That's true in general, but the business of tech can sometimes benefit from local knowledge. A submission about the best lawyers for tech startups in Singapore wouldn't really be appropriate for HN since it wouldn't benefit a large part of the audience.

It also helps to have a site where there's a high chance that the person you're talking to is close enough to meet up for coffee. =)

<comment><USER5> This is a fundamental flaw in communities on the net in general, they don't gracefully combine different scopes.

</comment></comment></comment><comment><USER6> Are you in Singapore? Would love to meet up.

<comment><USER7> Me too. Email in profile.

<comment><AUTHOR> Hey I can't see your email address. I think you need to move it to the _about_ field in your profile because the _email_ field is hidden from public view. My address is in my profile if you want to email me.

</comment></comment></comment><comment><USER8> So is the source behind HN available somewhere? Would love to setup it up for other verticals...

<comment><USER3> It's viewable here too [http://github.com/nex3/arc/blob/dca901c0cb59ebb533a511df3a84...](http://github.com/nex3/arc/blob/dca901c0cb59ebb533a511df3a844e578e4fa5d6/news.arc)

</comment></comment><comment><USER9> Great work. I think it would be great when you guys start cover the region, like Indonesia. I hardly can find any Indonesian startups so far. Unfortunately, i don't live in the country.

</comment><comment><USER10> Also, check <http://123emprender.com> for a spanish community about hacking/entrepreneurship

<comment><USER11> At least 123emprender.com took some liberties with the design. Sigint.sg took the design along with the functionality.

<comment><AUTHOR> It was actually never intended for sigint.sg to seem like it was created independently. There's a link back to Hacker News in the FAQ: <http://www.sigint.sg/faq>

<comment><USER12> While we are talking looks I might as well add that the light blue header doesn't go too well with the brown background. #BFDFF9 would look better.

<comment><AUTHOR> Ok noted. Let me mess around with that when the site is restarted next.

</comment></comment></comment></comment></comment><comment><USER13> What's the startup scene in SG like? _Also_ , are their consumer Internet companies mostly English-language, or multilingual?

<comment><AUTHOR> Not yet comparable to the bay area but definitely picking up. There also seems to be a genuine desire by the government here to see the startup scene flourish and they're allocating resources as such.

Consumer Internet companies here are predominantly English language.

</comment></comment><comment><USER14> It would be awesome if you or someone could make a similar version for New York City.

<comment><USER15> This is an interesting idea. Maybe it would solve pg's scaling concerns (not hardware & software but content & character) of HN to make regional sites covering NYC, Austin, Bay Area, London, etc. in addition to the top level 'global' one.

Make it a craigslist of startup/tech discussion and maybe even have the best local content percolate to a top-level/global page.

I think if you stayed on a local page you immediately get back to a vibe of the early days of HN simply because of the reduction in readers/commenters and realignment of interests (ie: the startup scene in Singapore).

<comment><USER16> One of the major issues here is that Hacker News hasn't been YC news for a long time. It's evolved on purpose to be something more than start-up focused.

Not that I don't like your idea, just that what you're asking for is a reduction of scope that I think pg has specifically not intended.

<comment><USER17> dont think sigint.sg was set up with what pg wanted in mind.

i would say that this is a great effort to start the discussion on region specific info relating to start ups which I think is what HN is not able to provide.</comment></comment></comment></comment>


Desperate Opera adds Webkit prefix support in Opera 12.5 - <AUTHOR> http://www.browsomatic.com/2012/07/desperate-opera-adds-webkit-prefix.html <comment><USER2> I've been an avid Opera user since the browser was adware and I think Opera has every reason to be desperate. Increasingly often I used Chrome simply because Opera doesn't work with the web apps I need for my daily work. Right now I'm seriously thinking about ditching Opera altogether and use Chrome as my primary browser, a decision that would have been unthinkable just 2-3 years ago.

<comment><USER3> Opera may lose some market share at the desktop, but they are still a very strong contender in the embedded market with support for many different targets.

I know that Opera here in Linköping, Sweden, is currently trying to hire a lot of people and that seems to be the case globally too:

<http://www.opera.com/company/jobs/list/>

</comment></comment><comment><USER4> I find myself returning again and again to Opera - I like chrome and chromium, but I live and die by bookmarks and they don't work well in google's browsers.

It seems like Googles engineers have a very short attention span and can't be bothered to go back and fix fundamental problems which have existed for 2 years now.

</comment><comment><USER5> This is a scandal. All the web developers that have been screaming about IE for years are now too lazy to add the moz-, ms-, o-, and the general version of CSS properties.

And I do not think it is an excuse that one browser does not support an property, put in the prefix or at the very least the general version, feature versions will probably support it.

</comment><comment><USER6> > This marks the return of Monopolies in internet ...

... and I stopped reading right then and there. People, Webkit is open-source FFS. The comparison with the IE6 situation doesn't hold water.

<comment><USER7> How exactly is this different to gecko webkit etc having to support non standard features shipped in MSIE because lazy developers wrote shite code?</comment></comment>


Please do not use Feedburner service - <AUTHOR> http://www.garron.me/blog/why-you-should-not-use-feedburner.html <comment><USER2> I debunked this months ago here on Hacker News: <http://news.ycombinator.com/item?id=4215474>

Here's more info: <http://support.google.com/feedburner/answer/79590?hl=en>

The short version is that FeedBurner has a free feature called MyBrand which serves your feeds from a CNAME of your own domain. Then if you choose to leave FeedBurner, you still have full control of your feeds and permalinks. I set it up on my own domain years ago as feeds.mattcutts.com, for example.

I think this free feature of FeedBurner is one that everyone should use so that you keep feeds under your own control and served off your own domain.

<comment> g-garron Hi Matt, first thanks for getting the time to read my post, and replay. The problem I still see is that even if you have your domain the link is messed up. From your blog.

<http://feeds.mattcutts.com/~r/mattcutts/uJBW/~3/8IurStR5fXw/>

Goes to

<http://www.mattcutts.com/blog/pubcon-2012-slides/>

So if I bookmark the former, and FB dissapear you will have to create a full list of 301 redirects in your server so my links still work. Yes you have the control, but that is a lot of work.

Why not make FB links like this?

<http://feeds.mattcutts.com/blog/pubcon-2012-slides/>

In that case all you have to do is a 301 of feeds to www.

Hope my point is clear.

Edit: never mind. Someone found this [http://www.wangarific.com/how-to-get- rid-of-feedproxy-links-...](http://www.wangarific.com/how-to-get-rid-of- feedproxy-links-in-your-rss-feed/)

That way you really have all the control back.

</comment></comment><comment><USER3> Two minute search: [http://www.wangarific.com/how-to-get-rid-of-feedproxy- links-...](http://www.wangarific.com/how-to-get-rid-of-feedproxy-links-in- your-rss-feed/)

TL;DR: disable click tracking.

<comment><USER4> It isn't even on by default. I signed up recently (just remembering that Feedburner did this thing with feed statistics, not knowing that they had removed the API) and it had a specific warning along the lines of "enabling this option will modify the content of your feed"

</comment></comment><comment><USER5> It seems weird that he uses blog-centric companies (TechCrunch, etc) as examples of companies that do, and non-blog-centric companies (GitHub, etc) as examples that don't.

TechCrunch/etc cares about the statistics FeedBurner offers since that is their core product, whereas GitHub/etc probably don't care that much.

<comment> james-skemp Exactly right. I think the post is wrong, so I might be bias, but the examples were rather lacking.

</comment></comment><comment><USER6> Why? Just because every other time people gave complete control over their data and content it turned out be a bad idea and the the internet itself was invented to avoid this problem?

But it's different now, the companies involved are the ones I've read about since I was young and are therefore trustworthy and permanent. I know older people thought the same thing and turned out to be wrong every single time, but this time it's different. Why is it different? Uh ... I'll get back to you on that.

</comment><comment><USER7> The same applies to all of the link shorteners too. I've often wondered how much of the web would break if TinyUrl and Bit.ly closed.

<comment><USER8> This kind of already happened, in 2009: the URL shortener tr.im closed. Once in a while I still run across a broken tr.im link.

<https://www.macworld.com/article/1142188/trim_twitter.html>

</comment></comment><comment><USER9> For a serious blogger, Feedburner is a great way to reduce the traffic on your server. Many RSS readers are poorly developed and will hammer your server for no reason. Jeff Atwood wrote a great article about this a while back: [http://www.codinghorror.com/blog/2007/03/reducing-your- websi...](http://www.codinghorror.com/blog/2007/03/reducing-your-websites- bandwidth-usage.html)

</comment><comment><USER10> This is a bit of an old discussion.

I think it's a fair tradeoff for content-centric companies to have feedburner (now google) rewrite those links to get some very useful stats in return. This was already happening pre-acquisition and only got better afterwards.

Links get indexed quicker and get submitted to reader / google news for free.

</comment><comment><USER11> Is there some kind of analytics service that google provides with this? If so, can you turn it off?

<comment><USER12> Yes and yes.

The whole reason for existence of FeedBurner is analytics. The links are used to track clicks; you can turn it off.

</comment></comment><comment><USER13> I've never seen this happen -- at least with CNAME'd feeds. Can anyone else confirm?

<comment><USER12> This is an option that allows tracking clicks on the links. I believe it was turned off by default when I signed up.

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

</comment></comment><comment><USER14> I prefer Feedburner links because all they do is redirect. I have no problems with the t.co redirect that Twitter has. It's the same thing.

</comment><comment><USER15> By all means provide an RSS feed on your site. But Feedburner can help get your pages indexed in Google (and other search engines).

<comment><USER16> Is that difficult without Feedburner?

</comment></comment><comment><USER17> Does anyone have any experience with some FeedBurner competitors that they'd recommend? I'd be happy to pay.

<comment><USER18> I work at FeedBlitz and we have support (giant improvement over FeedBurner), analytics, integration with other social media for RSS distribution, easy-to- enable triggers and parsers to make the RSS part of integrated marketing communications.

</comment></comment><comment><USER19> Zero evidence, no credible reason not to use it. Suggesting that Google might sell feedburner to someone who then shuts it down is laughable.

<comment><USER20> That rather shortsighted. All companies, as well as governments, eventually hit financial trouble, and some day fail.

Google has shut down many services and "broke the internet" before - what they essentially did with Reader.

Even if it takes 100 years, we don't want the internet archives to be broken.

<comment><USER19> I think it's shortsighted to design your architecture for Google failing as a company. Google will be around far longer than either of us.

I'm not sure what you mean about Reader though?</comment></comment></comment>


Deploying Node.js with systemd - <AUTHOR> http://savanne.be/articles/deploying-node-js-with-systemd/ <comment><USER2> "Simply starting node on your server is a recipe for disaster. If it crashes (and at some point it will, node code is perfect), your service will be wiped of the internet."

The solution to that in the article seems an awful lot of trouble. You can just use the following in your script to keep it from crashing/exiting whenever there's an exception, warning or whichever:

process.on('uncaughtException', function (err) { //do stuff });

I've used that in a few projects, where it usually sends me an email if something goes wrong. (npm: mailer).

<comment><AUTHOR> That assumes that node itself will never crash, or that your server will never reboot.

Just keeping it running isn't the main point though: socket activation is great if you want to increase server density. And the whole-system monitoring + resource policies are very nice tools for system administrators.

There's a lot more to systemd and node.js than simply running node.

<comment><USER2> Good to know, thank you - will definitely have to try it out then!

</comment></comment></comment><comment><USER3> There is a lot of wealthy information in OPs post. The socket activation will be nice for some QA servers that I have planned.

</comment><comment><USER4> rubenv - Can you comment at all on using something like monit to watch node processes - we leverage it fairly heavily on our servers but have not really gone through as many steps as you have here. We use upstart to handle starts, stops, and restarts, and monit to watch for crashes.

<comment><AUTHOR> Monit falls in the category of forever: it's a duplication of your process manager. I think you can do some of these things with upstart as well.

If you are currently running Ubuntu and use upstart, by all means leave it like that: don't fix it if it ain't broken.

But do know that you miss out on some very nice things :-)

<comment><USER4> It does look that way, yes - some of the stuff you point out looks great and is worthy of consideration. I just was wondering if maybe we were way off base in our mechanisms - we are far from web ops specialists by any means.

Originally we did just purely use upstart to control things but it was pretty dreadful at doing certain things compared to monit, and we have a lot of familiarity with monit from our embedded hardware projects.

</comment></comment></comment><comment><USER5> socket activation is nice, but i dont think its intention is for something like this. if your app automatically quits after 5 minutes, and it takes a few seconds to start because initialization in node is synchronous, then this is just kind of weird

monit is great because you can get emails if your app goes down, it monitors files and all kinds of other stuff. you could easily use socket activation with monit so that a crashing node process drops as few connections as possible by passing along the fd to another node process, but then if you are going to do this you might as well use cluster and fork your node process.

tldr; many ways to skin a cat, but turning off your node process because it is idle is kind of weird because it has implications for the first visitor, and it shouldnt just be reached for as a standard way of running node

<comment><USER6> I believe the last slide shows that the restart takes 48 milliseconds, and I get similar results with one of my own processes running on our server. This doesn't seem like a big deal at all.

For large node programs, this approach may require careful optimization of the start process in the same way that we optimize the client-side page loading process.

<comment><AUTHOR> Chad_oliver is right: the impact is negligible. We wouldn't do it if it would deteriorate the user experience.

There's a lot of great documentation on the systemd site. An exact description of socket activation and its intended use cases is on there as well: this is definitely one of them.

<comment><USER5> different node processes start up differently, some can take a while. auto- quit after 5 minutes, really? socket activation is helpful for lazily loading things when a system boots up, so everything can be started in parallel and the order that processes come online doesnt matter. its been adapted to all kinds of things and im not saying it wouldnt work in some use cases to conserve resources, but socket activation + auto quit is a bit odd. node actually benefits from running for a long time or from being hit with a lot of requests -- even if your app starts fast you are trading this away among many other things...</comment></comment></comment></comment>


Tests of Some Deadly Diseases on Mice Mislead, Report Says - <AUTHOR> http://www.nytimes.com/2013/02/12/science/testing-of-some-deadly-diseases-on-mice-mislead-report-says.html?hpw

<comment><USER2> I've always wondered which early scientist chose mice, maybe they were a cat lover. It's funny how some commonly studied species like mosquitos or zebra fish have logical reasons (reproduce quickly etc.) But some are completely arbitrary.</comment>


Pokémon: Scaling to Catch Them All - <AUTHOR> https://www.apteligent.com/2016/07/scaling-catch-aka-pokemon-webscale/ <comment><USER2> Stating the obvious here - but more official launches to come, too.</comment>


That dd trick and the ballad of SIGINFO (2016) - <AUTHOR> https://stuff-things.net/2016/04/06/that-one-stupid-dd-trick-and-the-ballad-of-siginfo/ <comment><USER2> Will have to try that Ctrl-T trick on BSD.</comment>


Geohot on twitch livecoding SLAM (simultaneous localization and mapping) - <AUTHOR> https://www.twitch.tv/tomcr00s3 <comment><USER2> There goes my evening ...</comment>


What every programmer should know about memory, Part 1 (2007) - <AUTHOR> https://lwn.net/Articles/250967/ <comment><USER2> [https://hn.algolia.com/?query=What%20every%20programmer%20sh...](https://hn.algolia.com/?query=What%20every%20programmer%20should%20know%20about%20memory%20points%3E20&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

</comment><comment><USER3> Out of curiosity, can any hacker news types quickly tell me if there's been any significant developments since this paper was authored that a programmer should fundamentally consider these days?

<comment><USER4> Yes. Persistent memory: [http://pmem.io](http://pmem.io). This a storage medium accessible like memory and much faster than traditional disks. It blurs the line between memory and disk and will fundamentally alter the way we build systems.

For example you may no longer need a leveldb or sqlite disk store, you could just use plain data structures in persistent memory.

An early version is currently available with i3 instances on Amazon. Expect to hear more about this in the next few years.

<comment><USER5> Oh gosh no!

We already have something similar with memory mapped files. The original .doc format was just Word's data structures shoved in a memory-mapped file. That's why it was so hard to make 3rd party applications compatible.

Serialization, like xml or SQLite, is needed to ensure that a file format is interoperable among different programs and different versions of your program. How can you add a field to a data structure in version 2 when your data structures are so tightly coupled to your persistent data?

Furthermore, things like SQLite offer indexing that lets you find data without needing to traverse all your RAM in a foreach loop. It abstracts away your application's data's format from the algorithm needed to access it quickly.

And finally, what happens when your program crashes? What if your data structures are in a bad state, or corrupt? What about transactional integrity? How do you abstract your pointers, because the addresses of your structures will change the next time around.

I suspect that SQLite (and similar) will have updates that take advantage of persistent memory.

(Edit) I also suspect that persistent memory will help lower power consumption. A device could go into a kind of a sleep mode much more easily if it didn't need to page in and out its memory.

</comment></comment></comment><comment><USER6> Prior discussion: [http://news.ycombinator.com/item?id=1394346](http://news.ycombinator.com/item?id=1394346)

</comment><comment><USER7> Good idea to splice it up, makes it easier to tackle.

Link to full pdf by the way: [http://futuretech.blinkenlights.nl/misc/cpumemory.pdf](http://futuretech.blinkenlights.nl/misc/cpumemory.pdf)

</comment><comment><USER8> This one is also very usefull: [http://igoro.com/archive/volatile-keyword-in- c-memory-model-...](http://igoro.com/archive/volatile-keyword-in-c-memory- model-explained/)</comment>


Is Nginx obsolete now that we have Amazon CloudFront? - <AUTHOR> http://www.peterbe.com/plog/is-nginx-obsolete-amazon-cloudfront <comment><USER2> How does this shit make it to the front page?

First and foremost, everyone needs caching. It's what makes computers fast. That RAM you have? Cache. The memory in your CPU? Cache. The memory in your hard drive? Cache.

Your filesystem has a cache. Your browser has a cache. Your DNS resolver has a cache. Your web server's reverse proxy [should] have a cache. Your database [should] have a cache. Every place that you can conceivably shove in another cache, it can't hurt. Say it with me now: Cache Rules Everything Around Me.

First you should learn how web servers work, why we use them, and how to configure them. The reason your Apache instance was running slow is probably because you never tuned it. Granted, five years ago its asynchronous capabilities were probably haggard and rustic. It's gotten a lot more robust in recent years, but that's beside the article's point. Nginx is an apple, CloudFront is an orange.

Next you should learn what CDNs are for. Mainly it's to handle lots of traffic reliably and provide a global presence for your resources, as well as shielding your infrastructure from potential problems. Lower network latency is just a happy side effect.

<comment><USER3> > How does this shit make it to the front page?

Obviously the title was a little ridiculous, but I up-voted it, because it's a novel idea. If you're planning to have almost all of your static assets hosted from the CDN (which is pretty reasonable for almost everyone) then why bother with a super high-throughput low-latency web server if the only purpose is to occasionally refill the CDN? If you end up thrashing the CDN and constantly going back to refill it, you're going to have bigger problems.

From what I can tell, the rest of your comment is just super aggressive and doesn't really go anywhere. I will tell you that I have extensive experience with every piece you've mentioned here, and none of that really has any effect on the author's thesis (again, no need to optimize serving static content from your host if a CDN is going to do the legwork).

In general though, when someone works at Mozilla, I tend to give them the benefit of the doubt regarding their knowledge of elementary computing principles.

<comment><USER2> The problem is this isn't a novel idea. Replacing a fast webserver with somebody else's fast webserver is half of the reason most people choose CDN's (the other reason usually being bandwidth). Just using someone else's fast webserver does not obsolete a different fast webserver.

It's totally acceptable that you might not have the infrastructure to serve all of your static content from your measely web servers and 100mbit connection. CDNs are a great choice here. But this has nothing to do with what web server you use, nor does it mean you should process every request dynamically just because right now you have the resources for it using a CDN.

Even with a CDN and an extremely efficient static content layer, you still have to hand out dynamic content to your users individually which a CDN generally will not help with. At a high enough number of requests you will run out of resources (RAM, CPU, Disk, Network, etc). At this point it's handy to have the fastest things you can so scaling doesn't become one huge clusterfuck. Then whoever re-implements Nginx to help handle requests will write a blog post about how Nginx makes CDNs obsolete.

My point before (and now) is: Caching matters, and having a fast frontend web server matters, and CDNs matter, and none of this is directly related: we're talking apples and oranges.

As an aside, CloudFlare seems to use a novel little fast web server:

      psypete@pinhead ~/ :) wget -S -O /dev/null http://4chan.org/ 2>&1 | grep -e "^[[:space:]]\+Server:"
        Server: cloudflare-nginx
        Server: cloudflare-nginx

</comment></comment></comment><comment><USER4> More generally: once you adopt any of the various schemes for having a inbound proxy/front-end cache (Fastly, CloudFlare, CloudFront, or an in-house varnish/squid/etc), are all the optimizing habits of moving static assets to a dedicated server now superfluous?

I think those optimizing habits _are_ now obsolete: best practice is to have a front-end cache.

A corollary is that we usually needn't worry about a dynamic framework serving large static assets: the front-end cache ensures it happens rarely.

Unfortunately it's still the doctrine of some projects that a production project will always offload static-serving. So for example, the Django docs are filled with much traditional discouragement around using the staticfiles serving app in production, including vague 'this is insecure' intimations. In fact, once you're using a front-end cache, there's little speed/efficiency reason to avoid that practice. And, if it is specifically supected to be insecure, any such insecurity should to be fixed rather than overlooked simply because "it's not used in production".

<comment><USER5> Tools like Apache and nginx are not ONLY faster at serving files with less load on the system than a script. They are also more thoroughly audited and battle-tested. And their declarative configs won't go wrong just because the person writing them missed an unbelievably subtle corner case introduced by using a Turing-complete language.

It's important because there are so many opportunities for error in serving arbitrary files out of a filesystem with some rough and ready script.

For example, if you are serving files out of the same filesystem that holds your configs and secret keys then you should be a bit nervous. You have to get the permissions right and make sure you don't have anything improper under a directory which you are publishing as a whole. If your users are uploading files to the same place you should feel really nervous.

There are too many easy ways for people to be negligent and screw this up. In the context of designing an opinionated framework, you accept a lot of social liability and you are really dropping the ball if you are setting up tired and ignorant users to screw up this badly, without even a warning in the docs to think about what you are doing.

With n script languages and m static file serving implementations per language, there are now (n*m) obscure packages to audit. Not counting their combinations...

Your idea to just "fix the insecurity" and remove any warning from the docs means to do things which you merely believe to fix the insecurity, and then overlook the underlying risks of the approach.

I am also not sure you are right when you suggest that there cannot be any performance (or reliability) impact of pushing static serving into some script library. Just as these are not audited they are also not nearly as likely to be benchmarked and tuned.

If there is a reason to serve static files out of script, that reason will be because of some positive reason (like convenience or the need for some particular flexibility) rather than some vague sense that using Apache is "obsolete".

<comment><USER4> Here's the thing: Django makes the standard staticfiles app available. It's a great convenience, eliminating extra steps (collecting/moving static assets) and processes (another nginx/etc). And many projects' 'dev'/prototype incarnations are already open to the world, in one way or another.

So if this is a security sin, they've already encouraged its widespread commission. A bit of "don't do this" or "don't do this in production" hand- waving in the docs don't resolve a security problem, if there's a real vulnerability in the current implementation.

On the other hand, committing to the idea that the bundled staticfiles app may be used this way -- that in fact it's a _good_ and _modern_ way to operate, in production, once you have an inbound proxy cache -- would mean accepting deeper responsibility. It would give up the hedge, "if there's a security bug, we warned you!". It's not taking on n*m obligations: it's taking on 1 language, 1 module. And it's not even a new module or an obscure need... it's exactly the sort of thing an opinionated framework can solve for people.

The old opinion -- "take this risk in development, but by the time you get to production use the 'best practice' of a separate static server" -- should be updated to a new opinion -- "the 'best practice' is now a front-end proxy cache, which makes the performance benefits of an extra static server negligible, so we're no longer going to assume everyone will do that in production".

An admonition against using other less-tested code to achieve the same effect would still be appropriate. But not nonspecific FUD about the framework's own code -- that it is "probably insecure". Anything that's truly "probably insecure" ought to be fixed.

<comment> St-Clock "eliminating extra steps (collecting/moving static assets)"

Interestingly, we extended the collectstatic command in many ways to perform minification, combination of assets, generation of sass and javascript variables (based on settings in python), etc. It's part of our deployment and if we were serving static files through django, we would still have to run a similar command.

I'm also happy that nginx is handling file uploads, aliasing, redirection, virtual hosting on different IPs and Ports with different access control, real ip extraction (when behind a load balancer), etc.

I'll be following more closely this trend of moving static asset hosting from a regular web server to the application container, but I believe that web servers like nginx and apache can do a lot more than just serving static files (at least, in complex deployment scenarios).

<comment><USER4> That's certainly a value of a 'project prep step' (whether it involves static export or not).

Not also, though, that a service like CloudFlare now puts some of these optimizations (minification, asset-combination, obfuscation, etc) into the cache layer, as optional cloud 'app' services to be enabled/disabled/paid-for as desired.

Not saying that way is better for all, but it has potential as a convenience for some, getting those same expert-level optimization benefits while retaining a simple project/deployment structure.

</comment></comment></comment></comment></comment><comment><USER6> When you're only using nginx as a CDN, then yes another CDN can replace it.

nginx can do a lot more than serve static files.

<comment><AUTHOR> Nginx is not a CDN.

<comment><USER7> a hammer is not a paperweight

</comment></comment></comment><comment><USER8> Wait, so if I pay more for a CDN to deliver my static data, that will work better than when I try to save money and do it myself?

[Insert Oscar winning Face of Shock here]

</comment><comment><USER9> nginx still buys you SSI (which allows you to, for example, cache the same page for all users and have nginx swap out the username with a value stored in memcache), complex rewrite rules, fancy memcache stuff with the memc module (ex: view counters), proxying to more than ten upstream servers, fastcgi, and lots of other fancy stuff.

Cloudfront is a replacement for varnish, not nginx.

<comment><AUTHOR> Isn't that better to do in a programming environment you're more familiar with? LIke python/rails/ASP Then you have much better tools for building unit tests and stuff too.

<comment><USER9> The performance of doing it in nginx is _much_ better, and you can't do anything complex enough for unit tests to pay off. For the SSI stuff, you have your web framework of choice produce html with SSI tags in it, cache that, and nginx just swaps out the volatile bits at the last second (even for pages in cache).

</comment></comment></comment><comment><USER10> I was once told by somebody wise that if a post asks a question, then the answer is usually no.

e.g.: Is Mountain Lion going to kill Windows 8? .. etc.

<comment><USER11> A meta-corollary: whenever a headline with a question mark appears on Hacker News, there _will_ be at least one comment referring to Betteridge.

(Please, can this stop?)

<comment><USER12> Ultra-meta: Whenever a repeating meme occurs on the internet, there will be someone asking for it to stop. And the answer to whether it will stop will be no.

<comment><USER13> Recursive-super-ultra-meta-induction: Whenever someone refers to a level of meta-ness, someone else will refer to level n+1.

<comment><USER12> Transparently false: this thread's length is measurably finite.

<comment><USER13> For now.

</comment></comment></comment></comment></comment></comment><comment><USER13> Does anyone have experience with using nginx as a caching proxy? I've used Varnish and swear by it, it's just an amazing piece of software. How well can nginx replace Varnish?

<comment><USER14> It's great in tandem with Redis. [http://mikeferrier.com/2011/05/14/my- beautiful-dark-twisted-...](http://mikeferrier.com/2011/05/14/my-beautiful- dark-twisted-reverse-proxy-LRU-cache/)

<comment><USER13> Hmm, that looks very interesting, but I've had Varnish serve 100k requests on a small (512 MB RAM) VPS without me _actually noticing_ (I only found out when Google Analytics had a spike the size of a mountain).

Can nginx do that? It sounds like this solution wouldn't really be able to, having to go through Lua and all, but nginx is an all-around very solid piece of software too, so I wonder...

<comment><USER15> Nginx can handle much higher loads than Varnish in many situations.

Check this out for a look at Nginx's architecture: <http://www.aosabook.org/en/nginx.html>

<comment><USER13> I have read that, but what are those situations? I really doubt claims of "much higher" performance, Varnish is very, _very_ performant.

</comment></comment></comment></comment></comment><comment><USER16> I think not. Requirements change, and locking myself in to a front-end cache is not appealing. I may also have things which I can't or won't let others cache for me, so I want my local stack to be optimized anyway. You won't see me serving everything out of WEBrick anytime soon just because I have a cloud cache.

It's nice to be able to defer decisions, especially optimizations, but making performance someone else's problem entirely seems like it could promote sloppy thinking and poor work. It's the difference between augmenting a solid platform when the need arises versus front-loading dependencies because it's okay to be lazy.

<comment><AUTHOR> On several of my modern projects, there's not a single piece of static data that can't be cached forever in a CDN. That's because server-side code is not getting really good at managing the initial build of static assets and the delivery of their URL.

<comment><USER7> errr. just because it's static, and a pdf, doesn't mean you want it cached on amazons servers.

sensitive business documents and such.

<comment><USER17> If it's serious enough, why are you serving it as a static, unprotected resource?

</comment></comment></comment></comment><comment><USER18> There's a good post from late 2011, in the context of 12-factor deployment on Heroku, where the author muses about just using a pure Python server behind a CDN to serve static content:

 _...and yeah, I think I should bloody use this server as a backend to serve my in production._

[http://tech.blog.aknin.name/2011/12/28/i-wish-someone- wrote-...](http://tech.blog.aknin.name/2011/12/28/i-wish-someone-wrote-django- static-upstream-maybe-even-me/)

</comment><comment><USER19> Oh god, the file.read() then write to response method..

At least you should try `sendfile`.

</comment><comment><USER20> Sure it's obsolete, who needs databases and live, chancing data. All we need is a static pages. Besides who needs to build his own infrastructure, it's 2012 right ? Let's buy it.

<comment><AUTHOR> Is this just an odd joke? Of course you need a database.

If you need to build a toaster, you don't need to build an iron smelting plant. Certain things other folks are better at taking care of.

<comment><USER20> > _Is this just an odd joke? Of course you need a database._

Looks like we need a sarcasm alert on HN, like spoiler alerts :)

</comment></comment></comment><comment><USER21> If you want to serve static files cheaply and are moving less than 10TB/mo you will find that CloudFront is a magnitude more expensive than bunch of VPSes with lots of monthly bandwidth.

Viability of this depends heavily on the use but if you're moving funny pictures of cats then you won't be generating lots of income and want to optimize the bandwidth costs.

</comment><comment><USER22> Before implementing that, be aware that CloudFront doesn't support custom SSL certificates. If you have any user-session in your app, you don't want them to login on <https://efac1bef32rf3c.cloudfront.net/login>

</comment><comment><USER23> CloudFront is pretty good, just make sure you are able to config your asset source in one line. Otherwise you have to use a tool to invalidate the cloudfront cache frequently during dev and it's not instant.

<comment><AUTHOR> Invalidation is for suckers. A fresh new URL is much safer.

</comment></comment><comment><USER24> No.</comment>


Whistling Into a Tape Recorder: What the East Coast Doesn't Get About Startups - <AUTHOR> http://dangrover.com/2012/05/30/whistling-into-a-tape-recorder-what-the-east-coast-doesnt-get-about-startups/ <comment><USER3> Is it just me or does the non-technical co-founder really get killed by most blogs?

I have been approached a couple of times by friends with 'ideas', they just need a programmer to build it for them. I respectfully declined each time and remain friends with these people.

None of them ever got anywhere with their ideas. They never quit their day jobs, they never read the right blogs and books (even if I suggested, and in some cases bought copies of the books for them), they never raised funding, they never talked to customers, and they never found another programmer. They had absolutely no idea where to even begin on the business side of things, much less the engineering side.

I think programmers get all hot and bothered by the idea of a 'non-technical' co-founder undervaluing their contribution and so we all love these posts. But really, most of the people saying they are 'looking for a technical co- founder' aren't just lacking the ability to code. They are lacking the ability to do a startup.

Calling them 'non-technical co-founders' really is giving them a free pass. Most aren't ready to be co-founders, technical or not.

It also really belittles a good business cofounder (lets not term it around what they can't do, but what they can do). A good business cofounder goes out and talks to customers, has a handle on the market, probably has a contact list full of potential partners or employees, can pitch, do some PR, and hopefully secure some funding. That is very valuable to a young startup, and most of the people with an idea and no coder aren't up to that level.

<comment><USER4> >Most aren't ready to be co-founders, technical or not.

I think this is the crux of the matter. Most people aren't ready to be co- founders.

<comment><USER5> The only way you can get ready to do a start up is to do a startup?????

<comment><USER6> No. But if you immerse yourself in the language, the business and the culture of startups, you can learn enough to give it a shot. There's more to startups that 'tech' -- basic business skills are seemingly underrated by so-called technical people. The question should never be 'can we build it', but 'can we sell it'. A startup is a business, designed to make money. Building something with no business plan can be cool and useful, but a project doesn't become a startup until the project turns into a product -- which is something that makes money.

</comment></comment></comment></comment><comment><USER7> I ran into a toxic mentality on the East Coast where there was a class division between "thinkers/leaders" and "doers," and doing automatically placed a person into a lower class. The idea was that execution is for little people and ideas and "leadership" are for big people.

I met a bunch of over-stuffed narcissistic and ineffectual big people who could sell like crazy and drum up endless interest by way of their ivy league social networks but would then fall flat on their faces when it came to executing on anything.

<comment><USER8> I left a job a few years ago the moment that I realized that the people who were allowed to have ideas and the people who were allowed to implement ideas were always going to be, by deliberate design, different sets of people.

<comment><USER9> As an aside, that is also why it is dangerous for a company to create an "innovation" or similar department.

</comment></comment></comment><comment><USER10> This piece very easily could have been titled "Whistling Into a Tap Recorder" and had sent the same message (and a worthy message at that). After all, neither New York not the East Coast are mentioned until 90% through the article. But then again that title likely wouldn't have gotten as many upvotes on HN b/c apparently everybody likes a rivalry.

<comment><USER11> Absolutely, that title is just baiting. We're in the internet era now - <USER2> can we get over the east vs west or valley vs nyc rivalries? There are bad apples and fools in suits everyone in the world.

<comment><USER12> You're totally right -- did not need to drag that in as prominently. Revised the title.

</comment></comment></comment><comment><USER13> [edit: content removed as the site is back up]

HNed, it appears.

Google's Cache: [http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://dangrover.com/2012/05/30/whistling- into-a-tape-recorder-what-the-east-coast-doesnt-get-about- startups/&hl=en&biw=1311&bih=783&prmd=imvns&strip=1)

<comment><USER14> It's perpetually annoying that people make this an East Coast/West Coast thing (as if "East Coast" can even be generalized about... I'm sure Atlanta has a much in common with NYC as Mountain View has with Eugene). It's very small sample set of people to make any kind of good judgement, and seems to just be catering to stereotypes.

<comment><USER15> Yeah I am also constantly annoyed by this, I work out of a coworking space in the lower east side with tons of technical geniuses. It doesn't matter where you live, but who you associate with in that area.

<comment><USER12> What co-working space is it? Can I check it out? :D

</comment></comment></comment></comment><comment><USER16> I don't have a problem working with non-technical people who are 'looking for a technical co-founder', usually they identify as 'business guys'.

Just like 90% of coders can't write fizzbuzz, 90% of biz guys can't close a deal. The issue is not the 90%, it's finding the 10%.

The east coast has no monopoly on useless people.

</comment><comment><USER17> I love that this showed up the same day as the post about how Alexis Ohanian built reddit.

For those that don't know, Alexis doesn't code.

And he and Steve are from the East Coast.

But who am I to bash another good round of technical vs. non-technical Hacker News flaming?

<comment><USER18> Well Steve is a programmer, and from the udacity classes he teaches he seems like a damn good one.

</comment></comment><comment><USER19> I realize this is mostly irrelevant, but can anyone confirm/deny the Elfman claim?

(It occurs to me that you'd have to be a _fantastic_ whistler to manage some of, say, the spiderman score. Also, I'm pretty sure the guy _invents_ percussion in his basement.)

<comment><USER20> I'd imagine it's an exaggeration of some aspect of his real creative process. I wouldn't be surprised if he does whistle into a tape recorder while watching a rough cut of the film, I'd just be surprised if that's _all_ he does.

Actually it seems like a damn good way to write music for a film. First you figure out the basic themes at _leitmotifs_ that you want to use. Then you watch the film a few times and whistle or hum _basically_ how you want the music to go, so that you can match the music to the moment on a second-by- second basis. Hand over the tape to an assistant and let them worry about turning this vague musical shape into the outline of a complete score; once you've got the score you can worry about the details.

<comment><USER21> It's not in the slightest bit true about Danny Elfman -- in fact, it's farther from the truth in his case than any other film composer I can think of. With the amount of synth and guitar that Danny performs himself, he actually has up to half his _tracks laid down_ by the time the cue is getting approved by the director. Not only is he not outsourcing the composing, he's not even outsourcing the performance except where he needs to. And he's certainly not fiddling around with a tape recorder when he has a $100k+ Pro Tools rig in his studio.

All film composers have different processes, and it's true that few of them take on the details of notation, and all of them have teams that they work with. But you're absolutely right that that's a good thing, because that's how film music works: Turnover is extremely short (sometimes as little as a couple weeks to write an hour of music), notes on the page are _not_ the product, and specialization allows the process to move forward and the job to get done.

This blog post irks me in part because it's an unkind rumor, and in part because it's a completely inept metaphor.

</comment></comment></comment><comment><USER22> This might be like the third blog I have read about the east coast 'doesn't get' or 'can't do' startups. The last article said the east coast could not make a facebook. Check your facts. Facebook started on the east coast.

Anyway onto this article. How can you call yourself humble when your saying someone else 'doesn't get it' or 'cant do it' That does not sound humble to me. Other then that there is no substance to your argument.

Here is my prospective:

On the west coast, your startup fails, go work at another startup, get a real job at a profitable company, that fails, sleep outside in a tent.

On the east coast your startup fails, get a real job at a profitable company, or freeze to death.

</comment><comment><USER23> Um.

Boston Dynamics? DEKA!?

Yeah, maybe the east coast doesn't have social networks for cats, or iPhone apps for taking pictures of your food, but to say that they "don't get" startups is stupid linkbait.

</comment><comment><USER24> Very off-putting link title. Location has nothing to do with it.

</comment><comment><USER25> I think the recent, cool web stuff has made programming look easier, even though it isn't. Maybe we're closer to to the tech, maybe we can expect more from software. We don't really appreciate any of these 'simple' web services that solve a lot of hard problems (eg, scale). Twitter is only 140 characters, but it's definitely not simple. That way it seems to outsiders like the hard part is coming up with the idea, instead of the execution.

</comment><comment><USER26> "Techné"? Where do people get these? This isn't French, it's "Techne". As in "τέχνη". Or did we start accenting random létters now?

<comment><USER25> I dunno, it's on Wikipedia: "Techne, or techné, is a Greek term..." <http://en.wikipedia.org/wiki/Techne>

<comment><USER26> That's wrong, that accent has no place there. If anything, it would be téchne, because that's where the stress is. Techné just makes no sense. I think I'll change it.

</comment></comment></comment><comment><USER27> I am a non-technical founder, grandma, wife of a starving artist. All I can say is, ya gotta start somewhere. It's been gruesome, and awesome. Promoting local sustainable commerce. Free online neighborhood Storefronts. Http://ourtownzip.com.

</comment><comment> mck- too much traffic?

<comment><USER12> Trying to get the server back up. Geeez.

<comment><USER28> interested in the numbers

</comment></comment></comment><comment><USER29> I realize OP already altered the title, but I just want to reiterate that this is a universal problem and has zero to do with East vs West</comment>


Fidus Writer 3.3: Citation management integration - <AUTHOR> https://www.fiduswriter.org/2017/10/11/fidus-writer-3-3-citation-management-integration/ <comment><AUTHOR> Fidus Writer is a collaborative writing tool for academics built on ProseMirror. I've used it in the past but found citation management clunky. I might give it another try.</comment>


Wavve: making $76k a month turning podcasts into videos - <AUTHOR> https://www.failory.com/interview/wavve <comment><USER2> My favorite podcast app ([https://overcast.fm](https://overcast.fm)) does this, here's the creator's post about it: [https://marco.org/2019/04/27/overcast-clip- sharing](https://marco.org/2019/04/27/overcast-clip-sharing)

</comment><comment><USER3> Semi-rhetorical question: why do customers accept something like this delivered in SaaS form? It seems so antithetical to customer obsession when this is the exact type of problem that lends itself well to a locally running application.

Why not deliver this as a desktop application that users download and pay for one-time? There's absolutely no need for an ongoing subscription to a backend service here. Outside of rent-seeking.

<comment><USER4> Semi-rhetorical answer:

1\. It still provides more value than the monthly subscription.

2\. People have shown a greater willingness to pay for ongoing features and support in a SAAS model than in other formats.

3\. It better aligns with the costs of support and maintenance that the provider needs to provide.

4\. It's less risky for the consumer to get started.

5\. There's no piracy or people decompiling your app and putting it out under their own name.

6\. No updates to fiddle with and works across machines.

Not all answers above directly apply to the podcast->video service here but these are the general reasons.

<comment><USER5> I built and sold an installable application in the past, and #5 was brutal. For some reason it's rarely discussed.

<comment><USER6> I had a customer openly admit to me that they had been using a pirated version of my app until now.

Pretty crazy when you see your own app on torrent sites.

<comment><USER7> Only when your goal is making money and not making apps to further humanity

<comment><USER8> Making money allows you to invest. If you can't make money, the scope of what is possible is restricted to "what one guy can make as a hobby".

Not all problems are workable within that constraint.

</comment></comment></comment></comment></comment></comment><comment><USER9> I made something like this once for a podcast. FFMPEG is a godsend. Essentially I took a video (could just be the logo image made into a video) and looped it to the length of the audio track. Essentially it just called ffmpeg with the right parameters. The process only took a few moments and gave me a video I could upload to YouTube.

Back then I was really surprised that I couldn't find a service like this. Had I found one I probably would've used it.

</comment><comment><USER10> God that's impressive. takeaway: make products for people that use computers but don't know how to use suites of tools.

<comment><USER11> Maybe your takeaway is right but there's also a huge piece that wasn't captured in your one-liner

"We lost about 2 years of our time and $30k of my savings (which was most of it). "

"Getting those first 10/100+ customers was really hard. We relied primarily on direct outreach via cold email and social media messaging to obtain those first customers. Taking the time to reach out directly to customers for a $7/month plan was painful"

<comment><USER10> that's because all of that goes without saying (since I assume that the typical hn reader already knows about 1. pivots being costly 2. the early adopter grind). those points aren't key features of their succuss either because every startup experiences those pains.

<comment><USER12> Or you could look at it another way. Perhaps there are many, many that would be successful if only you can get past the first obstacles. The success may be less due to it being a good idea and more to do with overcoming the obstacles. I often wonder how things would be viable businesses if you were good at grinding.

<comment><USER11> I think most of the "overnight successes" are just stories where people look at the end results without point out the steps in the middle.

Outside of the few "lottery winners", most are grinders that didn't commit business suicide.

Major props for those who grind until they can share their tales.

</comment></comment></comment></comment></comment><comment><USER13> I must be thick but... I have no idea what their product does after reading the interview. Can someone explain it for the rest of us?

<comment><USER14> Sure! Previously, podcasters and musicians didn't have a very engaging way to share audio on social media. We built Wavve so creators can easily convert audio files into a branded video with an animated waveform. Here's our Twitter and Instagram accounts with some examples of what's possible:

[https://www.instagram.com/getwavve](https://www.instagram.com/getwavve)

[https://twitter.com/wavve](https://twitter.com/wavve)

<comment><USER15> Oh, doesn't seem like very much.

<comment><USER16> It really doesn't. An experienced dev could recreate the core features in a web app within two weeks or less.

The more difficult part:

\- Understanding the work that goes into making and releasing a podcast

\- Figuring out that a step in the process is not being done efficiently

\- Determining a balanced set of features whose delivery and maintenance cost is low enough that people in industry will benefit from paying for them

\- Marketing your software to potential customers

\- Convincing them that they will benefit from purchasing your software

\- Maintaining the software to satisfy your customer base

\- Exploring and releasing new features to stay ahead of your inevitable competition if the product is successful

\- Taking the initial risk to start development

But everybody here knows that already.

<comment><USER17> Also want to chime in that just building the core features (or shall I say a very simplistic version of the core features assuming two weeks time) isn't going to make an app successful. Rather, it's handling the endless amount of edge cases and the different ways your customers will end up using your product.

</comment></comment></comment></comment></comment><comment><USER18> I wonder if it is possible to make a simple version to run entirely in the frontend, for short clips?

You can capture video and download it from canvas: [https://developers.google.com/web/updates/2016/10/capture- st...](https://developers.google.com/web/updates/2016/10/capture-stream)

And it looks possible to add separate audio to it: [https://stackoverflow.com/questions/39302814/mediastream- cap...](https://stackoverflow.com/questions/39302814/mediastream-capture- canvas-and-audio-simultaneously).

You could also recreate the waveforms and add to the canvas: [https://developer.mozilla.org/en- US/docs/Web/API/Web_Audio_A...](https://developer.mozilla.org/en- US/docs/Web/API/Web_Audio_API/Visualizations_with_Web_Audio_API),

Not widely supported, but you could try to add speech recognition too [https://developer.mozilla.org/en- US/docs/Web/API/Web_Speech_...](https://developer.mozilla.org/en- US/docs/Web/API/Web_Speech_API/Using_the_Web_Speech_API)

<comment><USER19> Probably possible, but what would be the advantage? I know for instance using something like Google Speech to Text API is a lot more accurate than Web Speech API.

<comment><USER20> The advantage is reduced server costs + more efficient use of computing resources in general. I personally am always happy to offload processing to the client side wherever possible.

<comment><USER19> For the user?

</comment></comment></comment></comment><comment><USER19> I made a similar website here inspired by wavve [https://0work.co](https://0work.co)

<comment><USER21> I really miss a preview / demo here.

With wavve, I instantly see how the shared clip will look like. I can even scroll down to the social media links and see a lot of examples directly in instagram / twitter / facebook.

<comment><USER19> Added a demo on the homepage.

<comment><USER22> I think your demo would be a lot more enticing if you fix the captioning. It flows poorly, omits critical words, and has spelling and word choice errors.

</comment></comment></comment></comment><comment><USER23> Love to see brain genius programmers charging money for a Fourier transform of some audio.

<comment><USER24> 76k mrr with some contractors, this guy is printing money and I'm very jealous.

<comment><USER25> Unfortunately, making a lot of money with software and the technical complexity of said software are weakly correlated.

Or maybe it's a good thing because it means a stupid simple idea can make you a millionaire

</comment></comment></comment><comment><USER26> I didn't realize there was such a strong demand for this kind of service. How does one go about knowing there is a market for things like these? I assume you also need to be somewhat involved in podcasting in this case?

</comment><comment><USER27> The actual website in question: [https://wavve.co](https://wavve.co)

</comment><comment><USER28> I was thinking maybe they used Deep-fakes to "turn podcasts into videos" haha

</comment><comment><USER29> Baird is an amazing person. I've had the chance of talking to him and seeking advice while building out my own podcasting platform ([https://kyrie.fm](https://kyrie.fm)), and he's given invaluable feedback to younger, budding entrepreneurs. Great job Baird and team! Hope to see the platform grow even larger.

</comment><comment><USER30> Just watching the marketing materials and presentation once again highlights just how important marketing is. Well done on that front.

<comment><USER31> Having been in a few failing businesses I can tell you that marketing and sales are _the_ core reason tech (maybe also non-tech) businesses fail. Fundamentally you can do without code, but you can't do without sales.

I have a lot of respect for sales people and people who can market themselves. One of my favorite videos about this is by a bodybuilder/powerlifter Stan Efferding [1] - he is some sort of marketing savant, with a product that I think is kind of silly, but he can market the hell out of it.

1\. [https://www.youtube.com/watch?v=bjFhe8yHKdY](https://www.youtube.com/watch?v=bjFhe8yHKdY)

<comment><USER32> "I can tell you that marketing and sales are _the_ core reason tech (maybe also non-tech) businesses fail."

Could not agree more, especially underestimated by the vast majority of devs turned entrepreneur. But you don't have to be that statistic - get a complimentary cofounder/partner/outsource if it's not your passion.

</comment></comment></comment><comment><USER33> Question related to video encoding: We are spending quite a bit of money on Amazon ElasticTranscoder for video encoding. Wondering if anyone had experience or advices to selfhost that kind of service? Any project I should consider for a proof of concept?

<comment><USER34> Elastic Transcoder is hilariously expensive. And in traditional Amazon fashion, is just a roundabout way to call ffmpeg. You would almost certainly be better off bundling ffmpeg into a Lambda function, and you would almost certainly be best off with an EC2 instance, two S3 buckets for the input/output, and an SQS work queue.

Check out [https://github.com/binoculars/aws-lambda- ffmpeg](https://github.com/binoculars/aws-lambda-ffmpeg).

<comment><USER35> Exactly what I was looking for lately. Thank you!

</comment></comment></comment><comment><USER36> I got a question, clearly a SaaS like this can easily be a desktop application if someone wanted to make one.

When your business starts making real money, at what point are you forced to start buying out these standalone apps so that your business model isn't threatened?

</comment><comment><USER37> Inspired by the Overcast variant of this kind of tool, I built a very basic browser based version using canvas and various web audio/video apis. It was fun to build over a couple weekends, but it ended up not being usable broadly due to speed (runs in realtime linear) and browser limitations of file export types (webm in chrome). If ffmpeg could reliably run in wasm, there could be alternative approaches. I concluded after I built it, I should make a headless non-browser version and it would be more usable, but haven't gotten around to it.

<comment><USER38> I spent a day or two last week trying to get ffmpeg.js working and it was nothing but headaches. If you had more luck I'd love to learn some details.

My use case: trim and append multiple (4+) MP4s in the browser into one continuous video.

</comment></comment><comment><USER39> Why do people reveal this stuff?

Seriously there's lots of people happy to clone it and get a bite.

<comment><USER40> There's probably more people who see a successful product in a space (thus social proofing the brand) and want to pay to use it than those who will actually pull their finger out and build a competitor.

<comment><USER32> "There's probably more people who see a successful product in a space (thus social proofing the brand) and want to pay to use it than those who will actually pull their finger out and build a competitor."

Of course there are, in fact I drove a few customers to them based on this post! Never heard of the service before and it looks interesting in the right setting.

However, it only takes 1 or 2 determined competitive efforts to start taxing your saas business even in small ways that only make life harder. Is showing your hand worth the trade-offs? That's up to each individual to answer. I know entrepreneurs / developers sitting on both sides of this table - doing the copying and being copied. Way of the road.

<comment><USER17> My take on this is if the market is big, it's not going to matter anyways since large markets will naturally attract competitors based on the amount of people screaming for solutions. If it's a niche however, you're probably best keeping to yourself about it.

One caveat is if your target market is entrepreneurs then being open about it might help differentiate yourself from competitors.

<comment><USER32> Totally. And depends on what the upside of signaling is? Some entrepreneurs like to drop their numbers so that they can generate competitive inbound finance or acquisition interest without having to shop round. It also attracts talent. Transparency can be an incredible powerful competitive advantage too.

</comment></comment></comment></comment></comment><comment><USER41> Interesting how so many startups get a break by effectively email spamming (or "cold calling" as they refer to it).

I've seen this a lot in stories like these as a way to get started and gain initial traction.

<comment><USER10> it's called outbound sales. there's no "big break" there. literally everyone does it.

</comment></comment><comment><USER42> That is insane revenue <3

<comment><USER43> That's pretty tiny revenue. It's about the turnover of a restaurant (pre- coronavirus).

<comment><USER44> Seems like there is very little overhead, so the profit must be huge unlike restaurants.

</comment></comment></comment><comment><USER45> (no affiliation) [https://www.headliner.app/](https://www.headliner.app/) will do this for free < videos/month.

<comment><USER46> The side thinks I am using Chrome, while I am on Firefox

</comment></comment><comment><USER47> Nobody should be making 76k a month when millions of hard working Americans are barely making 1k a month /s

<comment><USER48> I can't tell if you're trolling...

Also I find it hard to believe that there are millions of Americans who barely make $1,000 a month.

<comment><USER49> Check out [https://graphics.wsj.com/what- percent/](https://graphics.wsj.com/what-percent/)

Plug in $12,000 as the annual income, and that'll tell you that 24% of U.S. workers made that or less in 2014.

Looks like the number of full time U.S. workers in 2014 was 118.72 million: [https://www.statista.com/statistics/192361/unadjusted- monthl...](https://www.statista.com/statistics/192361/unadjusted-monthly- number-of-full-time-employees-in-the-us/)

That works out to be 28 million U.S. workers making <= $1,000 per month. Considering that's excluding part time workers, that should be make the calculation fairly conservative.

See also: [https://howmuch.net/articles/how-much-americans-make-in- wage...](https://howmuch.net/articles/how-much-americans-make-in-wages)

The specific numbers have changed in 6 years, but I don't find it all that unreasonable to suspect that there are many millions of U.S. citizens making less than $1,000 per month.

<comment><USER48> Do you have access to a formatted source of the data that was used to make the percentile calculator ? They claim it is based off the 2014 American Community Survey's Public Use Microdata Sample, but clicking on the provided link takes you to a directory with hundreds of zip folders.

Also the last link to "howmuch.net" states that their numbers include any wage earners whatsoever.

"There is one important caveat to keep in mind when thinking about our dataset. The SSA numbers include any wage earners whatsoever, even part-time workers like students and teenagers. If the worker reports his or her income to the IRS on a W2 form, he or she is included in these stats."

<comment><USER50> Why single out part timers, students and teenagers? How does any of that matter when talking about Americans earning less than $1000/mo? "These Americans make less than that, but let's not count them"???

<comment><USER8> Teenagers are supposed to have a support net, and be in school. It is not abnormal for them to have a living wage.

The same is true for students, albeit in a lesser form. Nevertheless, students will rarely have full time, qualified jobs. They need the time to go to class, and have no qualifications or experience.

The fact that part timers are discounted, is because if you work 50% then it is to be expected that your monthly salary is half that of full time employment. Sure, some people may _want_ to work more but cannot, but for many it is a choice that enables them to do something else. Raising kids for example.

Were not counting infants or dead people neither. Because it would not make sense. The point is to understand the wage situation of people when their wages are not influenced by something else, so that we can compare.

</comment></comment></comment></comment></comment></comment><comment><USER51> Similar but with less features and free: [https://marco.org/2019/04/27/overcast-clip- sharing](https://marco.org/2019/04/27/overcast-clip-sharing)

</comment><comment><USER52> That entire article seems like the same person doing the questions and answers

"What makes you so resilient against failure and so damn charming?"

But seriously I dont take issue with the concept of those kind of conversions, the problem I have is they tend muddy search results.

<comment><USER53> Huh? There are no sorts of leading/praising questions like that in the article. If anything, I found the questions to be very generic and templatized - which again isn't a bad thing and seems to fit the profile of the overall site (a resource for young startups/curious entrepreneurs)

The questions (for those who won't click through):

"What's your background, and what are you currently working on?" "What's your backstory and how did you come up with the idea?" "How did you build Wavve?" "Which were your marketing strategies to grow your business?" "What are your goals for the future?" "What were the biggest challenges you faced and obstacles you overcame?" "Which are your greatest disadvantages? What were your worst mistakes?" "If you had the chance to do things differently, what would you do?"

<comment><USER52> The questions were soft even for little league. most interviews are marketing pieces, but this might as well been an infomercial.

But at the end of day there is no innovation.

<comment><USER32> ...and what's wrong with a commercial for a proven successful saas in a world of fail+noise...suggesting you can't learn something from it?

Or are we to assume you commercial efforts are well exceeding $76k mrr?

</comment></comment></comment></comment><comment><USER54> Sounds nice... but _Sigh_ , only iOS?

<comment><USER55> It's a one-man effort (Marco Arment). It's not reasonable to expect him to develop for multiple platforms.

<comment><USER56> The market for indie apps is far better on Apple devices in general. More people are willing to pay for an ad free, nicely integrated app than on Android.

<comment><USER57> Source?

<comment><USER58> As for paid versions of Monument Valley, sales from the iTunes App Store far outpace sales on other marketplaces. Purchases on iOS account for 73 percent of Ustwo's $14.4 million of revenue, while only 17 percent of that total revenue came from Google Play.

[https://www.polygon.com/2016/5/20/11724058/monument- valley-s...](https://www.polygon.com/2016/5/20/11724058/monument-valley-sales- revenue-download-numbers-ustwo-games)

<comment><USER59> This particular data point is irrelevant since the game launched on Android one year after its iOS debut, losing the novelty and marketing factors.

<comment><USER60> Do you think it was a random factor that had it debut on iOS.

Despite far fewer devices, the Apple App Store has always made more revenue than Android. The most recent real numbers [0] I could find show this is a big difference.

I always assumed that's why app devs roll out on iOS first.

[0] [https://www.fool.com/investing/2019/10/11/as-usual-apples- ap...](https://www.fool.com/investing/2019/10/11/as-usual-apples-app-store- revenue-leads-google-pla.aspx)

<comment><USER59> I didn't contest the overall conclusion, but as engineers and entrepreneurs we normally have a propensity to disregard binary thinking. The numbers in your link are useful to predict expected revenue from an iOS vs an Android exclusive. The 73/17 ratio from the parent post is not, but could be misleading to someone who didn't know the app's release schedule.</comment></comment></comment></comment></comment></comment></comment></comment>