antileet

This is super impressive - both the pedigree of the team and the approach you took.

The funny thing is - when I first saw ploy, I didn't take it very seriously since so many of the signals that used to signify quality (decent design, copy, hard technical problems) are easy to fake. Plus the "grow while you sleep" space is crowded with weak players.

I wonder what the new markers of quality will be, which would separate the hand-crafted (to the extent possible) work v/s slop.

Maybe I'm missing something. If I use `git status --short` or `git log --oneline`, I see output similar to your tool's.

I can't tell if this is satire or not.

Have you considered storing it on the blockchain instead, so this way it is immutable and permanent? /s

Electron was originally known as "Atom Shell"!

Having built desktop software - I found doing things cross platform is hard for various reasons.

1. You can't use any specialized features or APIs in one OS unless you implement it in all others.

2. If you use Electron you're basically building a webpage, which can only be taken so far in terms of user experience. While teams like VS Code have pushed the limits, you still can't do what this app is doing.

3. Increased test/QA surface area which becomes difficult - especially supporting Linux - which have relatively fewer users but you still have to properly invest time into supporting it, something startups cannot do.

I really don't see the point of this product, but there are plenty of small to medium teams which are mac only, and it's better to be an interesting niche rather than yet another collaboration and huddle-type software.

Hi! I'm Andy and I have 12 years experience in a wide variety of roles - web applications with a variety of technologies and desktop applications and networking applications with C++.

I have been at my last role for about 5 years and am looking for a change to focus on a Senior Full Stack Engineer role.

    Location: Toronto, ON
    Remote: Yes
    Technologies: Laravel, VueJS, React, Python, Node

Similar JavaScript programming game running in the browser - http://jswarrior.fusioncharts.com/

Me and a friend built this in 2013, built on top of ideas from the original ruby-warrior.

For lightweight use among friends, I found that gogs works much better for me. Has a tiny subset of features but reliably creates/manages repos.

https://gogs.io/

I use https://getgrav.org/ and this is why:

- No DB. Use a flat file layout similar to Jekyll or static site generators.

- Offers dynamic features like redirecting and custom routing when you need it. This isn't possible with a pure static site generator.

- Decent optional panel to write, edit and manage almost all aspects of your site.

- Quite fast once you set it up with good caching.

If anyone's looking for similar functionality for PHP (Database-level time-grouping, time-ranged drilldowns, charts), you can check out http://razorflow.com

(Disclosure: I am the developer of RazorFlow, and am only posting here because I feel it's relevant to this particular story)

Actually, we are working on adding support for TV/Kiosk mode where the components update the data regularly, and you aren't limited to showing only one set of components. The dashboard will slowly and automatically cycle through all different components so even if you have more widgets than your screen can handle, it'll still work better than not being able to work at all.

The main difference is that Dashing is focusing more on current KPIs and Metrics. While we believe that those are crucially important, sometimes they just aren't enough for people who have data that's too much to get condensed down to a single indicator.

Well, maybe you can take a look at another dashboard framework I wrote. It uses PHP, pulls data directly from MySQL and works seamlessly on mobile browsers, tablets. :)

http://razorflow.com

Adding support for Google Analytics and Excel in the next two weeks!

We are going to release a version with PostgreSQL support shortly.

RazorFlow PHP generates SQL code according to the requirements and filters, and must take the differences between the SQL dialects of different vendors into account.

Hi,

I'm from India. I can't get the book shipped here without incurring large delay and shipping costs.

I would be happy to pay full price for a PDF and instant delivery. I'm sure there are more like me

It's a 3-hour hack - built for the purpose of me meeting more hackers in the city.

The code is open source. Feel free to modify and I'll incorporate your changes. https://github.com/ninjagod/apps.ninjagod.com/

I put this up just today morning:

http://apps.ninjagod.com/app/hackersocial/

I have noticed most people have their email addresses publicly displayed (in some human readable form), or have web pages with ways to contact them. In that note, I have been contacted via HN before and have met some people as well. Considering the ultimate purpose of a Private Messaging feature is to allow communication between two willing parties - the existing infrastructure is already there.

Moreover, more influential people who very strictly value their time and privacy (Matt Cutts for instance) might not be comfortable having an open avenue by which anyone can contact them.

More importantly, if you have someone's full name, there's a reasonably high chance you can find a proper way to contact them - provided you are determined enough to do it.

The page seems down for me. Fortunately, I happened to find the text in the cache.

"Jeff Bone <jbone at place.org> on Sat Feb 24 10:09:30 PST 2007

    Previous message: [FoRK] Bone's Corollaries to Philip Greenspun's 10th Rule of Programming
    Next message: [FoRK] And then there's Haskell...
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> Odd that this has come up -- I was just looking at Common Lisp and > Scheme implementations, as well as a smattering of Haskellish tools

And then there's Haskell...

Haskell is like "that girl." You know the one...

You never really went steady, but you'd run into her from time to time while knocking around in disreputable joints, usually late at night, every several months or so. She looked so hot, so sleek, so sexy, so expressive, so exotic. You'd end up back at her place and the night would just... take off. A complete blur of hot, sweaty, feverish, delirious, fumbling passion. You'd do things to each other... you'd do things to her, she'd do things to you... things that you're not even sure have names, that you're pretty sure are illegal almost anywhere. Even her kinks have kinks --- and after one of these nights, you'd realize that you yourself had a lot more kinks than you. And it wasn't just physical, it was --- cerebral. Ethereal. Transcendent. But it would all whiz by in a blur, and by morning you'd find yourself lightheaded, a bit confused, and stumbling homeward to your regular gal.

Over the next few days and weeks you'd find yourself occasionally drifting away, thinking about her. Haskell. You'd be there, banging away at your regular girl, and find yourself thinking "you know, if I was with Haskell, I'd be doing this completely differently." You'd think "I could be doing so much bigger and better stuff with Haskell." Now, your regular girl, she's not as exotic as Haskell. Pretty, maybe, if you're lucky. (Perhaps your regular girlfriend's name is Python. ;-) But not nearly as --- weird. Wild. Cool. Exciting. Don't get me wrong --- your girl, she's wonderful. You've got a wonderful relationship. She's --- comfortable. You can bang away at her all day and night. She's accommodating. Easy going. You work well together. But --- confidentially --- she's, well, maybe just a little bit boring. You'd catch yourself thinking these things, and the guilty pangs would get to you... You'd quash the thoughts, buckle down, and get back to banging away. Comfortable... there's a lot to be said for that, ya know? Comfortable... just keep telling yourself that.

Months would go by. Late some night you'd find yourself out, disreputable places again. Maybe that hacker bar, LtU. Somebody'd slip you an URL for some renegade paper, you know, one of those papers. You'd run into Haskell again. And the whole thing starts over.

Eventually, you're going to get the ultimatum. Haskell's ultimately just like any other girl on some level; she needs commitment. Eventually, after one night of wild, feverish, kinky, abstract passion, she's going to say to you: "All these times, and you don't understand me at all! You know, you're going to have to get serious, mister! I've got needs, too. You're going to have to get serious about my monads, or that's the last time you're going to play with them! Got it?"

...and then, you've got to make The Choice.

Chances are, you're going to go back to your regular gal. Haskell's just too much for any one man, probably. She leaves a trail of broken, brainy, embittered PhDs and former programmers behind her. She ruins you for the RealWorld. You can ride a while, but you probably can't go the distance with her. Go back to your regular gal and try not to think too much about what you've seen. Done. Felt. Thought.

Maybe you can salvage a little happiness; but it'll be hard. After all... you've tasted Haskell.

She's not like anything else.

jb"

I think there was a project to do that - and smooth out another few emacs quirks. I don't know how much it's being maintained though, but it was built by Xah Lee (afaik).

http://ergoemacs.org/

I'm a vim user, not an Emacs user (though I have dabbled with emacs before). If you still use vim on the console, you can do a lot better.

There's a reason why vim has support for multiple buffers. That you can keep multiple files open simultaneously. Read about vim remoting, and you can use a single gvim instance (which offers better performance and font rendering), and edit all files in just that.

Even in emacs, buffers are everything. Nobody opens a new instance of emacs for each file.

It's called a "Soft Hyphen"

http://www.cs.tut.fi/~jkorpela/shy.html

While it makes sense to make usernames consist of only alphanumeric characters (something people are used to - thanks to email), I don't see why you'd need to "sanitize" Unicode characters.

Email me, I'm sure you can come along as well when Vivek and I meet on saturday.

Suggestion: make your contact information available on your HN profile.

If you're interested we could meet one-on-one for coffee or beer sometime. I'm aggressively trying to network and find a co-founder or a project as well :) My contact information is available through my profile.

If I know correctly there'll be a Startup Saturday in Bangalore at IIM-B. I'll be there to pitch and announce my product as well. :)

It was a very naive implementation and it clearly has several faults. Thanks for pointing some of them out. There isn't any solid use case, and we're all better off letting nginx/apache/$SERVER handle the encryption rather than doing it inside the application.

I was just trying to jump on the "Look mommy! Look at what I can do with Javascript and HTML5" bandwagon :)

The way I see it - forms, multipart-post, etc came first, and then people found a way to abuse this to create login forms. Actual "HTTP Authentication" does a Base64 encode to make it Unreadable to the naked eye. It would be nice if I could tell the browser to hash the data before sending it to the server like so:

    <input type="password" name="secret" hash="yes" />

That wasn't the reason for Hashing the password before sending it to the server. It's common knowledge that a lot of people use the same password for many lower-rung services.

So if I send MD5 ( Password + Salt String), even if the attacker sniffs this and logs on as the user, the original password string isn't compromised, despite the fact that the salt string is publicly visible.

You're right. I didn't assume that the initial page can be hijacked as well. My small hack was just to try and work around the problem, while I understand it's best to rely on proven solutions like SSL when things get serious.

Thank you for pointing out where I was wrong.

I have a basic proof-of-concept workaround to prevent Firesheep and other HTTP Sniffers from seeing data sent from Client -> Server and Server -> Client. I will announce it here when I get enough time to get it to properly work.

Since the concept is so ridiculously simple, I'm sure anyone can trivially implement it. The only issue is that it needs HTML5 Local Storage to work.

    1. HTML rendered by the server has a small piece of code to generate an RSA Key Pair on the client using Javascript.
    2. The randomly generated keypair is stored on the Client using the HTML5 Local storage mechanism.
    3. For every request that the client sends the server, it sends the RSA Public key along with it. Also, the Server's Public Key is known by the client, and all outgoing data is encrypted.

Of course, this won't mean that the entire Website will be secure. It'll be quite trivial to create a small script to force all Form Data to get encrypted with the Server's public key - thus making sure that atleast your Passwords aren't transmitted in Plaintext.

In fact, with my current startup's application, the user's Password would never even _leave_ the client machine. Javascript would perform an MD5 hash, and the server treats that as the client's password. The issue with this is that you'll need JS active on all browsers for it to work.

This is one of the planned features for the next release. Users can say whether a tutorial works for them or not, and based on their User-Agent, the system will be able to guess whether it should work for a new user or not.