Show HN: The static, static site generator - <AUTHOR> https://github.com/xeoncross/Jr <comment><USER3> What a great idea, I'm really impressed with the cleverness and execution.

A few thoughts and questions for you (you may have already thought of/know about):

\- Have you thought about "well-formedness" for the HTML? I realize that adding anything besides the script tag would sort of ruin your point, and it would be nice if browsers accepted that, but also I feel there are sometimes hidden benefits to serving a well-formed document under the correct content type that the server said was being sent (or extension).

\- This makes your site awesome to read with a text browser or curl.

\- About 1/2 or 1/3 of the times I click "back" or "next", I can't scroll the page after it renders. (Chrome/MacOS)

\- The footer support is cool, have you thought about how you would do more extensive template support? (Maybe there's no reason anything extra couldn't be placed in the footer -- analytics, even a header -- although I think a favicon might need to be in a `<head>` tag). Integrating this directly with Markdown, too, could be really cool.

\- P.S. Your footer link says "Chanpter" :)

Great work, I love when I find something like this -- really clean, simple, and challenges the norms in a clever way. The result even appears quite polished.

<comment><AUTHOR> Thanks for the feedback. That is really what this project was about - <USER2> outside the box to solve problems.

Like most projects, I would expect elegant solutions to some of these problems to appear as more people think about the concept. I must admit, it works pretty nicely for such an abuse of technology.

</comment></comment><comment><USER4> Another neat show of letting the client deal with the rendering.

From the example[1]:

"You see, there is really no need for the server to generate anything for simple article-based sites like this. If the user wants to read your blog they can spend a few processor cyles[sic] to render the page themselves."

This paradigm is beyond me and it seems to be growing for whatever reason. Client-side processors rendering bytes through a separate engine, other than the HTML one, only to have it eventually run through the HTML engine so the client can actually read it.

The thought that everyone has a decent machine to do the processing is, in my experience, _still_ a false one. This was true 5-10 years ago, and I haven't seen evidence that it isn't still true today.

Your server probably has many, many cores. Probably SSD architecture. It is barely blinking to answer a request and deliver text. Why on earth would you leave the simple job of wrapping markup around text, to a machine that you know nothing about?

The average Internet user isn't terribly savvy. Their browser is possibly cluttered with add-ons. Their computer more than likely running 100s of background processes they know nothing about.

Depending on the stats you look at, in 2014, we're looking at a lot of folks with dual-core machines and a couple GB of memory, if they are lucky.

I can't understand why you would want to delay or hinder the experience to getting to your content.

While it may load really fast on your Macbook Pro Retina, or ThinkPad X1, that has a few text editors open and an up to date browser, the experience won't be true for everyone.

When did it become trendy for developers to put burdens on their clients with all of this front-end first thought? Just because it makes it easier for you to write and deploy, doesn't give you the excuse to put the burden on the user for rendering your stuff.

How many more times do we need to read about companies being forced into dropping this ill-conceived paradigm because they realized it made the experience for the client _worse_ , and in many cases, made the development worse as well?

In this example, we end up with an HTML file that is all of 6,084 bytes.

To get there in this example, we used jr.js, a 5,616 byte file, to load showdown.js, a 14,859 byte file, and render 651 bytes of text. Sometimes, the loading and rendering is _so slow_ , that the code itself has handling for it:

       	// Empty the content in case it takes a while to parse the markdown (leaves a blank screen)
    	jr.body.innerHTML = '

';

21,126 bytes to generate 6,084 bytes of text which has to now be rendered (one more time) by the browser.

Wouldn't it be great if there was some standard about the bytes that were delivered over the wire that everyone could use and build upon? Folks should get together and build a really good processor of bytes coming over the wire that's delivered in a particular format to be rendered on the screen. It would be great for the Internet! You could browse the entire thing!

[1] - [http://xeoncross.github.io/jr/](http://xeoncross.github.io/jr/)

<comment><AUTHOR> A server should serve. I to think too much front-end magic will slow down a site.

However, I actually created this on that dual-core laptop you are talking about. So not to take away from your point, but let me also take this from the other perspective - bandwidth.

The 6kB + 15kB Javascript files only initially seem to be a waste. After you think about the bandwidth you save transferring all the additional pages in plain markdown and using the (now) cached JS build each page actually results in much faster loading times even if the browser might have to spend a few hundred milliseconds rendering.

<comment><USER4> > A server should serve. I to think too much front-end magic will slow down a > site.

> However, I actually created this on that dual-core laptop you are talking > about.

Right, which is why you have stuff in your code about dealing with the fact that sometimes rendering the bytes coming down the wire is painfully slow. You commented out the spinner GIF, which has replaced the Java applet loading, or the Shockwave loading, we knew so well in the 90s and 00s.

> So not to take away from your point, but let me also take this from the > other perspective - bandwidth.

It would take visiting 3.4 posts of the size in the example before you would even reach the necessary bandwidth of the very first post.

Blog posts, by and large, get traffic for the single post in which someone is visiting and very, very rarely get hit up for a 2nd, and even more rarely a 3rd story on the same site.

Taking that into consideration, who is wasting more bandwidth?

> even if the browser might have to spend a few hundred milliseconds rendering

Gather up 3 or 4 times waiting a few hundred milliseconds and now you're waiting multiple seconds. Which is more than enough time for folks to hit the back button.

I'm not dogging your efforts or your library. I hope you don't see it that way. I am simply saying that the amount of work going into client-heavy development these days, and the amount of folks hopping on the: "Wow, that's such a great idea!" bandwagon, should be limited (educated).

A server should serve clients. There are human beings attached to the requests. We, as developers, should hold ourselves to a higher standard of doing whatever we can to remove burden from the clients.

I don't know where the idea that developers should be unburdened and servers shouldn't work hard came from, but it stinks.

Pay $0.00000001 to ask the 16 CPUs to wrap text in markup. Sheesh.

<comment><USER5> I'm sure there exist edge cases where the average user's browsing experience is slowed more by the additional bandwidth used downloading gzipped HTML tags on the fourth and fifth pages they visit than by the rendering script download on the first page and their browser running a script to generate a static layout features on every page.

But even then I'd wonder if the answer to save all that wasted time and bandwidth wasn't "maybe we could do even better if we compressed those images?"

<comment><USER6> I think the "edge case" here is "many if not most mobile connections" \- not everyone has LTE and even among those who do, it's a highly variable experience.

In addition you are hitting those clients with a double-whammy: slow load over a slow connection, and slow rendering on a [relatively] slow CPU.

<comment><USER5> The edge case is one where the extra bytes in a set of plain old HTML files are actually more of a significant overhead than the JS/markdown alternative, which has a higher page weight for the first visit anyway as well as making more demands on client-side renderers. (In retrospect I could have worded the first post more clearly). Mobile is hardly likely to be this edge case since as you point out yourself mobile browsers will have a more perceptible delay when it comes to generating a page on the client side in javascript (and also can't display anything until the script is downloaded which is possibly a _big_ first page performance hit, and aren't necessarily effective at caching the script for repeat visits)

</comment></comment></comment></comment></comment></comment><comment><USER7> Interesting, I wonder do search engines crawl pages like this?

You'd need to add at least a `doctype` and `title` for this to be valid HTML5 (not that it necessarily matters for a search engine crawler).

Edit: Also if you added the script to the top of the doc then you could `display: none` the doc and wait for the css to load before making it `display: block`. This would overcome the FOUC effect.

<comment><USER8> As I understand it, wouldn't Google render this page while crawling? Perhaps they'd punish it for doing so, but I think Google would have no issue with the content itself.

I also wonder how much FOUC you could incite by increasing the size of the markdown document.

<comment><AUTHOR> True, but don't forget that the JS and CSS is cached so after the first page load - every other page is instantly ready to be rendered.

<comment><USER8> That's not true in this case - the JS and CSS are cached but the output of the JS (the rendered HTML) is dependent on the _execution_ of the JS. If that meets any delay (ie, through parsing 1,000 nodes in a document for example), the page will look unformatted until the parsing is complete.

<comment><USER9> FOUC is easily enough fixed with some css rules. Can even give it a snazzy transition effect after it's rendered.

</comment></comment></comment></comment></comment><comment><USER10> I did something similar years ago with xslt rendering xml in browser. It used an xsl stylesheet loaded in the xml itself, similar to this approach. It was a pain to debug, and I'd imagine this approach is easier because tooling has caught up with this sort of thing.

I use httpsb so this comes through as a pile of text until I allow the js to do its thing. I'm ok with this, since a browser plugin that does markdown would work here too.

Sometimes I miss things like Archie that had very small network footprints due to technical requirements of the past. They really were able to focus on the content, like this solution.

<comment> X-Istence I loved the idea of using XSLT rendering to take an well formatted XML document and process it client side in the browser, but it came with more problems than it solved.

The tooling was terrible to accomplish it, but different browsers reacted slightly different to the XSLT, some had a flash of unstyled XML followed by it rendering the page using XSLT, JavaScript didn't work right since the page had to be served as XML not as HTML, Adsense my ad network at the time didn't work with it either.

XSLT had potential, but it never really caught on, and now we just have JavaScript frameworks that do all the rendering client side using JavaScript instead.

<comment><USER11> I noticed a similar flash with this project, although the end result is very cool, and to think except for links, this is somewhat all Lynx compatible.

</comment></comment></comment><comment><USER12> Now we just need a static site generator generator.

<comment><USER13> Have the server inject the javascript into the page?

</comment></comment><comment><USER14> Dang it, I was hoping for a 'pick your features & download your customized version of jekyll'! I guess that would be a static site generator generator...

</comment><comment><USER15> Static Site Generators seem like the Twitter client of today (which itself has been the "Hello, World!" of Web 2.0)

Here is a site that compares 270 of them: [http://staticsitegenerators.net/](http://staticsitegenerators.net/)

<comment><USER16> Most (all?) of those 270 static site generators generate HTML files that sit on disk on the server. This tool takes markdown files with a single script tag and serves that up to the client. While I'm pretty sure I've seen this idea before, it is at least different from the typical static site generator.

<comment><USER17> Many static site generators use (or allow you to use) markdown to write your pages, and then generate static html from it. And I can only see benefits to the no-javascript approach.

</comment></comment></comment><comment><USER18> If there's javascript in the output, it's not really static is it?

<comment><USER19> Well, you can deploy it with a simple web server. No server side processing.

Theoretically this is the best scaling solution.

Practically it makes the site slower for every client.

<comment><USER20> >Theoretically this is the best scaling solution.

Html markup on your pages is probably minuscule after compression (you're using zopfli with 5000 cycles and minifying your html, right?), and amortizing the upfront cost of that extra js over the average number of page views is definitely worse than plain ol static html for your blog 99.9% of the time.

But let's get real; theoretically the best? I doubt markdown is even near the optimum in terms of bits on the wire. Don't even talk to me unless you're writing your own binary markdown serialization format.

<comment><USER19> Well, with 1 client, you have one machine which renders the page and with 1000 clients, you have 1000 machines which render the page.

The processing capacity depends on the amount of clients.

With a static site generator, the processing capacity depends on your own machines and is independent of the clients.

But yes, for a static site, this just doesn't help much, since every client gets the same data, so why should every one process it on its own.

</comment></comment></comment></comment><comment><USER21> So am I right in thinking that this is like a template, but the template gets added dynamically by javascript?

<comment><USER8> You can confirm this by inspecting the document - the markdown is parsed into nodes through regexp and then a full HTML document is constructed and injected into the DOM (or rather, creating the DOM and then injecting it).

Cool, fun, but probably not something for which I can see a practical use.

</comment></comment><comment><USER22> I guess the only downside is that if your client has NoScript, they just see the raw Markdown. With HTML if the client has a text based browser things like links, images, etc will still work. I still use Lynx over SSH if I need to grab paywalled content from my work machine or check something on the local intranet when I'm out of the office.

The text based browser is splitting hairs, but NoScript isn't. Unless there are browsers that will natively render Markdown if served/detected (i.e. not a plugin)?

<comment><USER23> You could see that as an upside - Markdown is designed to be human-readable and is pretty successful in that design goal. So a NoScript user will see a rather nice plaintext.

<comment><USER24> uhhh, Markdown is "nicely" formatted for geeks, and is great for easing the burden of content creation.

however My mom (and I imagine any non-geek) would have trouble reading the hyperlink format, and be completely confused by the strong vs italics, code, or block quote sections of Markdown.

<comment><USER25> Remember that we're talking about markdown being shown to people with noscript, something I highly doubt non-geeks are using.

<comment><USER26> Wouldn't it also be shown to people who merely have Javascript disabled?

</comment></comment></comment></comment></comment><comment><USER27> Using Google Chrome Version 34.0.1847.132 on Linux, if I open pages (e.g. [http://xeoncross.github.io/jr/](http://xeoncross.github.io/jr/), [http://xeoncross.github.io/jr/john1.html](http://xeoncross.github.io/jr/john1.html)) in a new tab that is not immediately focused, they never visibly render. I see that frequently with client-side-rendered pages.

</comment><comment><USER28> While not what I'd do for every site, it's a pretty neat tool for some use cases.

In particular, Heroku has moved to a similar setup with Boomerang [1] - a JS include that puts the nice Heroku branding at the top of your add-on configuration pages.

It neatly sidesteps the need to make a component/template for every single framework and backend in use by their different partners.

I could also see it being useful as an easy "drop in" way of tying the branding+nav together on a number of different sites within an organization (so your auto generated docs, your tutorials, etc all live on different systems but easily look the same).

1 - [https://github.com/heroku/boomerang](https://github.com/heroku/boomerang)

</comment><comment><USER29> What about accessibility?

<comment><USER30> This comes down to reimplementing a HTML rendering engine in Javascript. Accessibility is the least of their problems.

</comment></comment><comment><USER31> And now i want to generate a TOC ;)

<comment><USER32> Great point. Client-side can't do any meta analysis about the data, unless it fetches all the data. Which is a big waste of bandwidth and cpu.

<comment><USER31> Furthermore, unless you do some hackery in your .htaccess or something like that, there is not even a way to discover all existing pages.

</comment></comment></comment><comment><USER33> At first I balked because I positively hate frivolous use of javascript and in fact browse with noscript and only a few sites allowed, but then I realised something.

This is actually really good for people like me. If I visit with javascript disabled, I get a nice, readable markdown. If I visit with lynx, I get markdown. I can actually read your blog with curl, if I want to. This is pretty much the holy grail of graceful degradation right here.

</comment><comment><USER34> This is an awesome idea, and looks like it is very well executed. I have two suggestions:

\- Add some sparse html tags (i.e. a basic doctype/body), which can help with search engine parsing.

\- You'll notice that for a few milliseconds on page load, the text is shown before the JS rendering takes over. This can probably be solved via Javascript, just find a way to cache or pre-load the pages.

</comment><comment><USER35> I was hoping this was going to be a generator that generates static site generators, since they seem to be the hot new project.

</comment><comment><USER36> Neat idea. Is the "Download Jr" part required, or could it just be included from GH pages of the original repo?

Could make for a very quick & simple way to put up some content online while keeping it looking decent, and users could contribute new themes etc.

</comment><comment><USER37> Neat idea for very small, quick and dirty sites.

Pros:

* No build process (yet), source == build & no need for dev server * Easy to integrate client specific code (e.g. browser compatibility)

Cons:

* How to transpile to CSS/JS? * Apples-to-apples, slower than static sites with "build" process * SEO?

TBD:

* Client processing speed

</comment><comment><USER38> That demo looks amazing w/o JavaScript: [http://i.imgur.com/sgC4sdN.png](http://i.imgur.com/sgC4sdN.png) (</sarcasm>). Adding JavaScript as a SPOF cannot be a good approach -.-

</comment><comment><USER39> I would wrap the markdown in a gigantic < pre > so that when noscript is enabled, you end up seeing at leat markdown, and not a wall of letters.

As for advantages of this, it seems like it would be better for a more open web. If you put this on the web, it doesn't matter where you serve it from, I can send you really good well formed patches. On thing the web currently lacks is the ability to participate at a web scale. If I see something that I can improve and can get to the source, I'll send a patch or pull request. These days 'view source' means 'view generated code that nobody has seen'. This gets back to the roots of the web.

</comment><comment><USER40> Do we really need this level of overly extreme optimizing? Today's modern Web browsers are already doing the most layout and rendering with CSS plus CDN and client side cache.

</comment><comment><USER41> Broken? "curl -i [http://xeoncross.github.io/jr/"](http://xeoncross.github.io/jr/") Content- Type: text/html.

</comment><comment><USER42> I have had a, static, static site generator for many years. It is called gedit. I've heard Notepad++ is pretty good too.

</comment><comment><USER43> I think the idea is pretty neat, but the flash of unstyled content before the js kicks in really ruins it for me.

</comment><comment><USER44> > $then = "email" \+ "@" \+ "davidpennington.me"

Is this supposed to be PHP or Javascript?

<comment><AUTHOR> So here is my dilemma. I wanted to write it in Javascript, but the "then" looked lonely without some kind of starting context. I was going to write it in Go, but "var then..." kind of messed up the sentence. So I wrote it in PHP since everyone knows what that horrible $ is all about.

<comment><USER44> '.' is the proper string concatenation operator in PHP.

</comment></comment></comment><comment><USER45> I made a less-tricky, less-cool thing like this[0] and I still use it on my site today. It's really great to not have to recompile markdown or do anything other than a git-push on text files. The fact that view-source works on yours is super cool, though; nicely done!

[0]: [https://github.com/haldean/docstore](https://github.com/haldean/docstore)

</comment><comment><USER46> This is cool. I value pageload speed though, so I wouldn't use this myself.

</comment><comment><USER47> All we need is browsers that support and render Markdown.

Good work !!

</comment><comment><USER48> This is a fantastic little toy project! Thanks for showing me. I'm thinking about building this into something for hosting on servers with extremely limited CPU, such as an RPi.

</comment><comment><USER49> I'm fine with octopress but if I had to change to another static site generator I'd probably go with 'Go' due to speed improvements.

<comment><USER50> Hugo is a fully featured SSG written in Go. It's considerably faster than other SSGs and has a very easy installation.

[http://hugo.spf13.com](http://hugo.spf13.com)

<comment><USER49> I know spf13 :-), that's what I had in mind.

</comment></comment></comment><comment><USER51> This is a great idea that might be useful on free hosts that only allow static pages but I don't think that I would use it otherwise.

<comment><USER51> I would be curious to see what other uses it has</comment></comment>


"Fantastic" beats "efficient" - <AUTHOR> http://blog.asmartbear.com/fantastic-beats-efficient.html <comment><USER2> My non-profit organization sends writers into schools to teach writing/poetry workshops to middle and high school students (we shy away from "dead white guys" and New Critical Theory and toward practicality and accessibility).

We made the decision, very early, to not charge schools for these visits unless they offered to pay us. Even though Nebraska is doing much better than most states, economy-wise, most school districts are still facing a huge funding shortfall, and can't afford our rates.

Simultaneously, we decided that we need to pay our poets, as it's not reasonable to force someone to choose between teaching a sweet poetry workshop and being able to pay rent (for those artists of ours who are in school or who channel their excess funds to their own creative projects).

It's been a real struggle finding ways to expand our programming while still having enough money to pay everyone, and it's meant that I've done a few workshops pro bono (as has my executive director). Thankfully, my board of directors is on board with this philosophy, and is moving very proactively toward helping to close our current budget gap. Meanwhile, students who attend money-strapped schools still get to hear and see and write poetry that does not suck. My only regret is that we have more interested schools than we have the people or capacity to serve them all, which is the best regret to have.

TL;DR: My non-profit, in a similar philosophical vein to this article, tries as hard as it can to not charge for services, knowing full well that many of our clients can't afford them. This doesn't translate to business, but further reinforces the point that sometimes it's worth a bit of inefficiency.

</comment><comment><USER3> I'm not convinced about this point. The examples given (Zappos and Netflix) are, from what I know, extremely efficient companies, and likely were so from day one (in my experience, obsessive focus on efficiency doesn't magically arise one day... it's either there from the start or it's never there). My full response: <http://swombat.com/2011/1/24/provide-fantastic-service>

<comment><USER4> I think the title "fantastic beats efficient" doesn't accurately reflect the main point of the article, since there's no reason at all why you can't be both fantastic and efficient.

I think a more accurate (though significantly less snappy) title would be "Don't be afraid to do something fantastic just because the business model doesn't look lucrative at first glance."

<comment><USER5> True, although I guess what I'm really saying is that, given the choice, you might pick "fantastic" in certain cases, at least in one or two areas in which it makes sense too.

Obviously if you have a profitable company you are, in some sense, "efficient." The point is that going "above and beyond" takes more time and money than not -- which is probably inefficient, especially at first -- and the question is: Is that tradeoff worth it?

<comment><USER3> That makes more sense. I'm still not sure whether there is a trade-off involved, though. The more I think about it (particularly about the examples you brought up, Netflix and Zappos), the more I get the feeling that the efficiency led to the fantastic, rather than the other way around. I guess this is fairly difficult point to resolve satisfactorily, though.

<comment><USER6> I suggest you read Tony Hsieh's book Delivering Happiness. My interpretation of his history of Zappos is that they were fantastic before they were efficient.

</comment></comment></comment></comment></comment><comment><USER7> Wow, the author just discovered the concept of loss leaders. Someone give him a cookie.</comment>


From the Generically-Named, an Appeal for a Facebook URL Aftermarket - <AUTHOR> http://themetricsystem.rjmetrics.com/2009/06/13/facebook-please-take-my-money-i-want-my-url/ Generically-named Bob Moore begs Facebook to let him attempt to buy his name in vanity URL form (and generate them some revenue in the process) <comment><USER2> I got my facebook URL this morning. I had meant to try right after midnight, but then I completely forgot about the whole thing until this morning when I checked facebook and saw the notice.

I'm not totally sure what difference it makes though. Anyone who wanted to find me on Facebook could already search by name or email address.

I get that Facebook wants to be more like Myspace and make it easy for people to communicate the URL of their profile, but almost any pronounceable string is just fine.

Because of domain names, which you can actually own (mostly), there seems to be a concept that any popular service that lets you create unique string/ID needs to have your exact name or brand or whatever for maximum...something.

Meanwhile, you can buy your own domain name and host it for $10-$20/year. Put up a page with nothing but links to your various online profiles. Then tell people to find you at "me.com".

</comment><comment><USER3> (I posted this on the website's comments, but anyway:) It would be terrible etiquette if a big website like Facebook were to take money to take away someone else's username/unique URL so that someone else who wasn't fast enough could have it.

As much as I understand where you're coming from, you were simply too late to get robertjmoore, and the person who did get that Facebook URL should not be penalized because of your willingness to pay cash.

</comment><comment><USER4> This guy seems a little overly-desperate. I mean, $100? Really? Is a vanity URL worth that much?</comment>


Why and how the guitar went electric - <AUTHOR> http://www.bbc.com/future/story/20190307-the-electric-spark-that-changed-the-guitar-forever <comment><USER2> > There are periodic claims that the electric guitar is dead, but it remains > surprisingly resilient to further evolution.

I don't think it's dead, it's just that there's a ton of other options out there for kids who are getting into music. Being a rock guitarist playing great solos just isn't as cool as it used to be relative to newer musical adventures.

I must say though, it's been a while since I've heard a really unique and interesting guitar player. I do like Yamandu Costa. Perhaps it's my age but I have what I like to call a guitar fatigue, and other than a few Holdsworth records, I try to avoid that kind of music. It probably has to do with finding less time to practice on the instrument too.

I feel like we hit peak guitar in the 90s. There just isn't much room for new styles.</comment>


Live Map of the World Tour of the History Atlas of Ukraine and Neighboring Lands - <AUTHOR> https://www.google.com/maps/d/viewer?mid=1-msKMbFj9GOVFmXd5FcLCJWFbHW85WQo&ll=45.96097329832694,36.27721668698996&z=7 <comment><AUTHOR> This atlas published by members of _NASU Institute of History of Ukraine_ [0] in 2018, and full name is _«Terra Ucrainica: The History Atlas of Ukraine and Neighboring Lands»_ [1]

        ISBN 978-617-12-3719-3

Authors[2,3] of this atlas also are members of the _«Likbez: Historical Front»_ non-profit organization, which provide blog and educational resources on history, politics and cartography.[4]

[0] [https://en.wikipedia.org/wiki/NASU_Institute_of_History_of_U...](https://en.wikipedia.org/wiki/NASU_Institute_of_History_of_Ukraine)

[1] [http://history.org.ua/en/post/43220](http://history.org.ua/en/post/43220)

[2] [http://likbez.org.ua/en/author/vortman](http://likbez.org.ua/en/author/vortman)

[3] [http://likbez.org.ua/en/author/lystopad23](http://likbez.org.ua/en/author/lystopad23)

[4] [http://likbez.org.ua/en/](http://likbez.org.ua/en/)</comment>


Real World F# - <AUTHOR> http://blogs.msdn.com/b/dsyme/archive/2011/01/12/f-for-energy-trading-and-energy-portfolio-optimization.aspx <comment><USER2> Nice mention of unit testing, lack of bugs, and units of measure. Can't put down the exploratory nature, either.

The only nit I have is the way MS keeps wanting to pitch F#. I know the spin is to use F# for math-y type things, but I really don't know why you just wouldn't use it for everything. I mean, underlying it is the CLR and the OS. It's not like somehow if you know F# somehow you need to also switch to C# to make a window. In fact, if you keep it functional, many times your functions can work their way into what you previously thought of as framework code, simplifying the entire kit and caboodle. I find that every time I switch languages, start declaring mutable values, or framing up reusable classes -- I end up severely limiting my options for refactoring later on. And functional code is nothing if not hugely refactorable.

Simply because you can switch languages doesn't mean you have to, or even that it's a good idea to do so.

<comment><USER3> Yep, CodeDom and a little better VS integration and I would ditch C# for most purposes in favor of F#. I really like the language and wrote a couple small projects in it before the 2010 release, but since then I haven't found myself making an F# library in an existing C# project. On what criteria should I base such a decision, given that I'm not doing scientific computing, and have to inter-operate with existing mutable data structures, etc.? I wouldn't put an arbitrary VB library into a C# project either for that matter.

</comment></comment><comment><USER4> F#'s type system supports units of measure. It looks really nice: [http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/uni...](http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/units- of-measure-in-f-part-one-introducing-units.aspx)

</comment><comment><USER5> When you solve Project Euler problems you can see previous solutions. The F# solutions are astoundingly concise.

I regret I have not yet learned F#, but studying the Project Euler solutions would be a good approach.

<comment><AUTHOR> ML derivative functional programming languages are frequently ideal for project Euler in general - Haskell, f#, ocaml etc.</comment></comment>


Offer HN: I will build you a marketing campaign to get more traffic - <AUTHOR> I've learned so much from this community, I thought I would give back too. I've spent the past three years doing affiliate marketing, buying traffic on pretty much every paid traffic source out there and driving it to various products.
I will help you properly architect, target, build, and scale a marketing campaign on paid search, adwords, Facebook, or media buys. Or I can help you optimize an existing campaign you are already running. I know a lot of tricks about specific traffic sources- I would welcome the opportunity to apply them for the benefit of a fellow HN member's startup.
My email is in my profile- I look forward to hearing from you. <comment><AUTHOR> I want to add that I specialize in leveraging ad spend, spending money to make lots more money.I probably won't help you get more Twitter followers, but I will help you get more customers.

<comment><USER2> We could use something like that for historious, but we aren't the richest company in the hood. Do you have experience with tiny budgets?

<comment><AUTHOR> Yes, absolutely! The beauty of targeted performance marketing is that you can know very quickly whether something is working or not without spending lots of money testing.

<comment><USER2> Oh, great, can you help us then?

</comment></comment></comment></comment><comment><USER3> I have no current need for this, but as a techie this would probably be the most useful of the recent offers if I had my own website. I have no idea how this stuff works, it always seems like black magic.

</comment><comment><USER4> Hi il, I remember you as one of VWO's earliest beta users. Now VWO has matured and we have good traffic on the site. But we haven't done any paid marketing. So, if you've got some time, would love to chat with you on if there is an opportunity to be tapped here.

Sending you an email too!

<comment><USER5> Once emailed you about your wonderful service while it was in beta. Would love to take advantage of it as an online marketer and tie something like this directly into my own conversion analytics, but the pricing doesn't make it as viable when dealing with large volumes of traffic.

Quick question, does your service work with android/ios devices/all other JS enabled devices? On the web of course...

<comment><USER4> Ah, I see. A large part of pricing is actually human support, that's why it may seem expensive for larger volumes. (Per-visitor support requests is surprisingly as constant as per-visitor bandwidth needed).

Yes, VWO works with ALL mobile devices capable of executing JavaScript.

</comment></comment></comment><comment><USER6> It would be very helpful if you could document the process while you help someone (sort of like a case-study or maybe even a diary/blog?)

</comment><comment><USER7> Hi,

I'm sure you've got a deluge of requests already. Kudos for your offer. Like someone here mentioned, marketing is probably the single biggest hole for hackers hanging out at HN - so its heartening to see someone offering fill that gap.

Just wrote you asking help on <http://recruiterbox.com>

</comment><comment><AUTHOR> Thanks everyone for your emails, I've gotten 150+ people emailing me so far. I'm trying to work my way through them as fast as I can, but it may be a day or two before I respond to you. I'm seeing some interesting patterns emerge, I'll post a lessons learned type thing in a few days.

</comment><comment><USER8> Thanks for the offer. I'd like to get more traffic on videolla.com - that's my startup! Can you advice something? Thanks in advance.

BTW: If you need any RoR help here is my HN Offer:

<http://news.ycombinator.com/item?id=1838091>

</comment><comment><USER9> Hi, I am knew to HM. I am trying to break through with app which can change the way we do our daily internet research. I was wondering it this will be a good example? <http://beta.clickhint.com>

</comment><comment><USER10> Is this offer still on? My website gets a small but steady stream of visitors daily with some ads, but my problem is that I don't know how to scale this up effectively to get more traffic. I've contacted you by email by the way!

</comment><comment><USER11> Nicely done Ilya!

Those of you who think marketing can be postponed until you are ready for launch - I seriously urge you to reconsider. You should be thinking of marketing strategy before you start writing code.

</comment><comment><USER12> Thanks il. I'll send you an email about <http://www.rawsignal.com>

We just took the private beta label off, but are flummoxed with how to get users.

<comment><USER12> we're also curious about what marketing techniques you think would be worth our money + what a good message would be to the users.

we'd like to figure out one short sentence where people are like . . . oh i get it.

</comment></comment><comment><USER13> Great. Just sent you an email. Our site is at <http://commerce.exorbyte.com> and we need this type of help.

</comment><comment><USER14> I sent you an email about <http://contexium.com>. We can use your feedback on customer acquisition. Thank you, Il.

<comment><USER15> I like the idea of contextium, when does the service open to users?

<comment><USER14> We are open. I just sent you an email.

</comment></comment></comment><comment><USER16> Thank you so much! I was about to post a Request HN for this, I have a proven process with return customers and am ready to grow it. Email sent!

</comment><comment><USER17> Thanks, that sounds very useful. I'll send you an email in a minute.

</comment><comment><USER18> Sent you an email as well! Thanks!

</comment><comment><USER19> Oh my God I need this. Contacted.

</comment><comment><USER20> Thanks so much! Sent an email!

</comment><comment><USER21> Have you thought of writing an ebook about what you know?

</comment><comment><USER22> Sent you an email..thank you very much.</comment>


Launch HN: Sixty (YC S17) – Freelancer Marketplaces for SaaS Companies - <AUTHOR> Hi HN!
I'm David, one of the co-founders of Sixty (https://www.usesixty.com/partners). We're a fully-managed freelancer marketplace for SaaS companies. We give SaaS companies an experts.[domain].com that their users can go to for do-it-for-me help from specialist freelancers, whom we call "experts". We source, vet, and manage the experts. We've also built software to connect a user and an expert together via screenshare for on-demand sessions.
It's a common problem at SaaS companies that their users want more hands-on help than in-house support can provide, but it takes a userbase of around 1M people and an organic freelancer community to form around the software (think Google Certified Experts or Quickbooks Pro Advisors) before that can easily be provided.
We built Sixty to solve the problems we experienced during our time as Squarespace Specialists (Squarespace's version of experts). With several years under our belt, we noticed 4 major problems around the concept of an 'experts directory':
1) Most SaaS users need a little bit of external help to derive the full value from more complex software – despite the software increasingly intended to be DIY. Users usually only need to get over a few small roadblocks to succeed.
2) The company's goal of making software intuitive enough for anyone conflicts with the expert's goal of making more money. Experts all have project minimums that presuppose them taking over the whole project.
3) Companies would need user bases of 100k+ before they would be able to even consider creating an experts community.
4) Building a community platform is fundamentally different than what SaaS companies were founded to do. It bloats the business model.
Our goal is to be a better solution in each of these 4 areas: 1) So users could get smaller scope work accomplished – helping them be more independent and successful on the platform. 2) So the experts can be a part of a better community with increased pay and more stability 3) SaaS companies with smaller user bases can take advantage of the improved activation and retention that expert communities bring, and 4) So SaaS companies can focus on what they do best – building great software.
We'd love to hear your thoughts about what we're building with Sixty! And if you're building a SaaS company or are particularly skilled at any startup or SMB software (Segment, Mixpanel, Zapier, Customer.io, Mailchimp, Weebly, etc.), we'd love to learn from you. <comment><USER2> I'm someone in your direct market and had no idea what your service does for me for at least 2 minutes of being on your site. Why would I want a marketplace? What is an expert and what are they an expert of? So many questions... I'd look into your messaging, definitely. It takes a while to click and I'm still not 100% sure what you do.

<comment><USER3> While perhaps they should clean up the messaging, to me it's a curated marketplace for consultants that specialize in specific SaaS apps (say, MailChimp or Intercom) as opposed to most freelancer marketplaces that categorize by broader technologies like programming languages.

<comment><AUTHOR> Bingo :)

<comment><USER2> Yes, bingo. I'd suggest reading into how this person described your business. :)

</comment></comment></comment></comment><comment><USER4> Really cool concept but I think you need to really hone in your messaging and think about who is willing to pay.

SaaS companies already pay for customer success / help -- if you can really offer help as low as 0.50 per minute, can't you just sell that to the SaaS owner?

I'm sure you've done your research and asked both sides, but that stuck out at me first. If I'm on Zapier and want help, I'm much more likely to reach out to Zapier to get help than to pay a 3rd party freelancer on Zapier to help me.

</comment><comment><USER5> So it's a tool which other SaaS' can embed so their users can pay to get video-chat assistance from freelancers?

<comment><AUTHOR> Yes to everything except the embed.

We have a lot of ideas for embeds! Right now, the product is a subdomain (experts.[domain].com) that SaaS companies can link to from their site & support.

</comment></comment><comment><USER6> Love this. Enterprise are going to sign up like crazy. Will save employees countless hours and emails.

</comment><comment><USER7> This looks pretty awesome. I'm a marketing consultant and I use so many of these tools. The next time I get stuck with something I'll probably use you.

<comment><AUTHOR> Would love to have you as a user! Which tools do get stuck on most frequently?

<comment><USER7> Used to be Zapier, but now I'm pretty good myself. Going to need Shopify help pretty soon making sure a data feed is clean.

<comment><AUTHOR> I hear you on Zapier! I was in the same boat initially. I actually built the initial prototype for Sixty using Zapier and Google Sheets. Then built it on Bubble.is until we got Andrew (our technical co-founder) on the team. Wished I had experts on both of them the entire time.

Have a ton of great Shopify experts :)

<comment><USER8> Did you run into any limitations using Bubble?

</comment></comment></comment></comment></comment><comment><USER9> I am a bit confused. Is this basically a network where I can get help from an expert at a specific technology/application ? For example, if I am a zapier user, I can get direct help from a zapier expert ?

But then who is your target audience ? Is it SAAS providers (outsourcing their tech support to you?) OR the SAAS user (contacting you directly for help instead of the SAAS provider).

<comment><AUTHOR> All of this is correct.

Both parties are our target audience. Our goal is to partner with the SaaS companies and give them control over the freelancer ecosystems. We're also building for the end-user though because we think that mindset will ultimately result in the best product for them.

Does this make sense? I can see how it's confusing.

</comment></comment><comment><USER10> I like it! Would probably call it 'Customer Success as a Service' (CSaaS) myself

<comment><USER11> This is brilliant

</comment></comment><comment><USER12> If you want to find experts, a great way to grow that side if the platform would be to approach people on freelancer and upwork.

You would be able to grow that side of the business super easily!

Just an idea, and good luck!

</comment><comment><USER13> I get it and I think it's very neat and solves a real problem. You guys are basically providing on-demand product evangelists right?

</comment><comment><USER14> If i understand correctly this is like <company>.stackoverflow.com. Did I get that right?

<comment><AUTHOR> Kindof. It could evolve into something like a forum (presuming that's what you're meaning). Right now we're focused on strictly getting the end-users problems solved as fast as possible by connecting them with freelancers via screenshare.

Does that clarify?

<comment><USER14> Sounds like a good idea! Many items I end up stack overflow thinking "wish I could ask one more question to clarify this further with an expert".

</comment></comment></comment><comment><USER15> Congrats on the launch Sixty!!

</comment><comment><USER16> I swear YC admits more dumb shit each batch.</comment>


Say Goodbye to User Name and Password Logins, and Hello to 'OneID' - <AUTHOR> http://mashable.com/2012/03/20/oneid/

<comment><USER2> PrivateSky – Secure Information Exchange platform turns your HTML5 browser into a two-factor authentication token (no more username and passwords)

PrivateSky is protected by the first HTML5 2 factor authentication solution, SkyPin, using elliptic curve cryptography that requires no browser plugin and nothing more from the user other than their email address (as login) and 4 digit pin.

SkyPin makes up part of Incognito Keys, the other part being SkyKey, our integrated identity based encryption key management solution which powers PrivateSky. Incognito Keys does what no other encrypted messaging service can do; guarantees that we CAN'T SEE YOUR DATA. PrivateSky has absolutely no way to physically comply with requests to decrypt information in the PrivateSky platform. No Hushmail leaks of information. Absolutely no backdoors.

The company behind PrivateSky is CertiVox. We're the people that produce the MIRACL open source cryptographic library, used by hundreds of organisations large and small to protect their information assets. Our chief cryptographer is Dr. Michael Scott, one of the pioneers in elliptic curve cryptography. PrivateSky utilises a number of advancements in the field, and...well, we think it's cool, cryptographically speaking. It's also really easy to use. Most importantly, we are completely transparent about how we do what we do, cryptographically speaking. Unless these other services are declaritive about how they implement their security methods, it's security by obscurity. We invite you to read our white paper on the www.privatesky.me site. You don't have to sign up or give us your information in order to access this.

We just launched our global beta so PrivateSky is now publicly available to all. PrivateSky will always remain free, even after we come out of beta period. Please help us; sign up for your own account, use the service, and give us feedback to make us better. We would really appreciate it!

Cheers, Team CertiVox

</comment><comment><AUTHOR> I am curious to see if this gets traction, after some many attempts to unify the login experience.</comment>


The Hairy State of Linux Filesystems - <AUTHOR> http://butnotyet.tumblr.com/post/77317512/hairy-state-of-linux-filesystems

<comment><USER2> His argurment is completely bogus -- they're _less slim_ because they share common code? Did he even look at the symbols he's complaining about?

The only filesystem I have built as a module on my machine is the brand-new btrfs, it has 223 unresolved symbols, and guess what? They're all basic, neccessary shit that should obviously be shared: mallocs, libc functions, concurrency primitives, block IO, inode management, VFS api, generic datastructures, zlib, etc.

This is more simplicity, not less, and an example of something that fustrates interlopers about the Linux kernel development culture -- your module _does not_ make it into vanilla unless you're working at the same level as your siblings. If you have a systemic improvement to make, you make it to a lower layer, you don't get to keep your own toys.

This way all the filesystems are improved by the innovations of one -- it took years for the production-ready XFS code released by SGI to make it into Linus's tree because it effectively implemented its own VFS tools. Eventually all its improvements were merged into the VFS layer, the refactored XFS was merged in, and all users got a performance boost.

</comment><comment><USER3> I look forward to seeing what happens to filesystems as solid-state drives with intelligent controllers become more common.

Optimizing file systems for disc rotational latency is so last century.

<comment><USER2> But flash memory (even with intelligent controllers) still has physical constraints to optimize for.

For starters: there's the much larger (and variable) block sizes, the erasure constraints around blocks (you have to rewrite a whole block to modify a bit), and the much more atomic power-management possibilities (can do better than just idle 'spin-down').

<comment><USER4> _you have to rewrite a whole block to modify a bit_

Technically, you can change bits from 1 => 0; you need to erase a whole block to go from 0 => 1.

<comment><USER2> All the harder to optimize for -- you could make the bitmasks in the on-disk format inverted, but it wouldn't help any given that you're almost always going to modify an integer at the same time. I suppose you could use unary representations :)

Another related (and potentially conflicting) optimization would be for powersaving -- in solid state logic, boolean values are represented as 'low' and 'high', and since 'high' costs more power (and nand gates plentiful), many circuits get implemented in negative logic. That could mean that an on-disk format and it's inversion would have different power consumption!

</comment></comment></comment></comment><comment><USER5> Obviously a bit off topic, but his graphic representation is astounding. Though not quite a Tufte archetype, I gleaned more insight from the image than the article. Very well done.

</comment><comment><USER6> Asking the wrong question, looking at the wrong answer.

Who cares about this if the fundamental design of the file-system is flawed...

</comment><comment><USER7> _Slashdot was reporting yesterday that OSes are sliming down._

Don't worry, I got my proton pack right here for that Slimer.</comment>