Hacker Newsnew | past | comments | ask | show | jobs | submit | geetarista's commentslogin

This happened to me a while back. The only way I could "fix" it was to close Outlook, discarding all my changes. I then made the same changes but saved the rules after every tiny change. Somehow the changes all saved and I moved on.

I wonder if the state somehow becomes corrupted and Outlook has no idea what to do, hence the error.


gofmt ftw ;)


Formatting along those lines are just one vector that's used. This gives a lot of weight to the underlying AST of the code, so in order obfuscate, you'd have to have a program that scrambles variable names, placement and content of control blocks, etc. Basically, you'd need less an autoformatter and more an obfuscator, probably coupled with a deobfuscator to make the code as generic as possible.


Exactly my thoughts


Under jasode's thread, you can see that people are missing Paul's point. He's not saying that working with close proximity is the "best" way of working. Yet most people here are debating which type of work is. Each company, market, vertical, team, etc. will vary in manifold ways.

What I believe Paul is asking for is that companies have the option to choose. Right now the option is available to anyone to hire remotely in one way or another. This is not the case with physically hiring into the country. Almost every startup I've worked at has had issues trying to hire exceptional people from another country. In almost every case, we lost those hires to the system and were forced to start the search again.

If a small, remote, international startup grows fast enough and they decide that working together under one roof in the U.S. fits their new needs, they should have the freedom and choice to do so.


Instead of using the z script, why not just use cd and $CDPATH, which are built in? I have mine set to this:

export CDPATH=.:$HOME:$HOME/workspace:$HOME/gocode/src/github.com/geetarista

You can set it to whatever you want, then just use `cd` and not worry about using some other script.


I recently wrote a blog post about this here: http://robbycolvin.com/javascript-automation-in-os-x-yosemit...


Maybe it already does. Somehow this comment isn't dead: https://news.ycombinator.com/item?id=7791436. Not sure what it means, though.


It's probably a bit old-school for you but let me explain.

The RAMDAC in an 'original' old style VGA card only had 6 bits per channel, and 256 LUT positions (also called the 'palette'). This allowed you to select 256 colours out of a maximum of 262144 colours, or 2^18.

So the maximum output value was 252, or hexadecimal FC for each channel.

You can't really output 24 bit ('truecolour') then because every colour channel will miss the lower 2 bits, and what should be 'white' will be slightly grayish and so on (white then becomes hex 0xfcfcfc).

Does that explain it adequately?


That was a very good explanation, but I was actually referring to the state of his comment. Meaning that I was unsure whether it means that it is indeed possible to bring a comment back from the dead or if this comment was somehow an exception to his deadban.


    On behalf of all of Joyent, we are extremely sorry for this outage, and the severe inconvenience it may have caused to you, and your customers.
I hate it when people apologize saying maybe it was inconvenient. If someone is using your service and you fucked up, it is an inconvenience.


Doesn't mean everyone is affected by it. If I was hosting some unimportant website on their platform, I probably wouldn't even notice, and it wouldn't be an inconvenience to me. Silly thing to feel so strongly about.


Disagree. They acknowledge it may be severely inconvenient, not just an 'oops'.



Also check out Statsite, which is a C implementation of StatsD: https://github.com/armon/statsite


Yup! We actually linked to that from the article as an example C implementation. It's really solid and also has a Librato backend ;-). We're already using it on a several high-throughput services internally and it will probably warrant it's own post in the future.


Thanks for this! Looks really promising. I'm a huge fan of statsd, but it seems like something so much better suited to a single binary than a whole node setup.


Open sourcing it is a great idea. I'm sure many people would be interested and it would be a way to keep the project alive in some way, seeing as you've put so much time and effort into it.

Also, open sourcing it doesn't preclude the opportunity of releasing it for sale in the Mac App Store if time permits down the road. Textual is a great example of this:

https://itunes.apple.com/us/app/textual-irc-client/id4030126... https://github.com/Codeux/Textual


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: