Hacker Newsnew | comments | show | ask | jobs | submit | XLcommerce's comments login

This is the route I've gone. The core CRUD part of the app is PHP, and the real-time chat and document collaboration aspect of my app is node. Works beautifully. I've had so much fun working with node for the last few days.


could you give more details of your diet please?


It sounds like his diet is probably similar to mine. Last summer I dropped about 20lbs from ~155 at my highest to ~135 at my lowest. I've been less strict about it since then but the general idea was to keep my carbohydrate intake between 20 and 30 grams a day. It's actually not that hard at all and you get to eat a lot of really great foods. The best part is that it's non-restrictive. Low carb foods are very filling so for the most part if you're eating the right things you just don't have to count calories at all, your body does it for you.

For breakfast I eat eggs almost every day. Hard boiled eggs are a good breakfast because you can keep them in the fridge at work but however you like them is fine.

Lunch is usually either a breadless sandwich (a plate of cold cuts and cheese) or a salad with a lot of meat in it with a tasty, high-fat dressing (because I can). In a pinch you can grab a fast food burger and eat around the bun, but I don't recommend it because the bun is there to mask how bad the meat is.

Dinner is pretty easy, just increase your meat and vegetable portion and remove the starch component. I end up eating a lot of what I affectionately refer to as "slop bowls" which is just the ingredients of something like a fajita but without the wrap.

For snacks I eat nuts (almonds are my favourite, pistachios are great too but a bit higher in carbs), cheese, cold cuts, cut up veggies with high-fat dip (because I can), dark chocolate, and more cheese.

For drinks, anything low-carb is fine. I like black coffee or green tea during the day and whisky at night. Dry wines are also fairly low carb, and a few brands of beer as well. Oh, and water!

The best thing about this diet (and I hesitate to call it that, I'm never going to stop) is that you can eat really good food every day. I used to be like most people and try to restrict fat when I was trying to eat well. I would end up eating stuff like rice cakes or salad with very little dressing. Now my diet food is bacon, steak, rich cheese, butter, sausage, salami, and so on. I can practically gorge myself on this stuff and the weight still comes off.

I highly recommend going low-carb for anyone that's had problems sticking to traditional diets. And I also recommend watching this video if you're wondering why the hell people think we need so much starch http://www.youtube.com/watch?v=3vr-c8GeT34


> "The best thing about this diet (and I hesitate to call it that, I'm never going to stop)"

A minor nit pick: that's exactly what a diet is. Your diet is what you eat every day. What pop culture refers to as 'dieting' is more like a selective fast: a temporary change or reduction in diet.

And that's why 'dieting' doesn't produce lasting results for most people. Most of those diets do work. But people fail because they stop doing them. They don't recognize paleo or south beach or atkins as a lifelong change. They try them, get results, get comfortable then fall back into old habits and thus their old shape.

That's why it's key to approach changes in diet and exercise on the basis of what you will maintain. And ultimately why talking about relative benefits of various diets and exercises is silly.

The 'best' diet and exercise is the one that keeps you healthy and that you maintain.


This is true. I hesitate to call it a diet simply because then people ask what I think is going to happen when I stop, and because saying that you're on a diet has certain connotations that I don't identify with and don't feel like explaining.

Plus then I don't feel like I've "blown my diet" when I eat pizza or drink beer.


Yep, pretty much this. I do exactly the same thing with the fajita.

You pretty much can keep making the same meals, you just get rid of the filler stuff. The essence for me was to just stop eating so much bread, potatoes, rice or pasta. Before I would graze all day, switching to low carb got rid of my need to eat all the time almost overnight.


Try the South Beach Diet. It's pretty much focused on lowering carb intake, especially at the beginning. I tried it a few years back and lost around 25 pounds too. I had to cut out all of my carbs (at least initially), but you can eat all the dairy you like.


Seems like about half the issues you've mentioned relate to differences in syntax/behaviour. This is to be expected. That is what vendor prefixes are for. They are a known (and necessary) evil. Would you prefer to allow the design by committee approach to continue? We've already suffered through 10 years of stagnation due to this approach.

Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next.

This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine).

Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next.

On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully.

Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets.

Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder.

The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on.

If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.


Seems like about half the issues you've mentioned relate to differences in syntax/behaviour.

If you mean the bugs I described, then no, I think all of them are genuine bugs.

There's no way to justify Chrome not redoing page layout or repainting properly after a DOM or CSS update. That's just sloppy, and it's a serious problem if you're writing app-style pages. Unfortunately, I don't have a self-contained, reproducible test case: we see this a lot using toolkits like jQuery UI when showing (or not) dialog boxes, but unfortunately it's a bit of a Heisenbug, or possibly several Heisenbugs. The general issue has been reported somewhat widely in Chrome-related blogs, though, and IIRC there were some issues already in their bug tracker that looked like they might be related. The latter led to some blog posts suggesting workarounds with JavaScript that might correct the CSS calculation errors in at least some of the cases. The issue has been there for several months, and still hits us from time to time.

The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners horribly ugly and which seemed to take several attempts to finally get right. (Of course there were browser prefixes and so on in this area as well for a time, but that's not what I was referring to.)

The H.264 issue is just a mess. The fact is that Chrome supported it, and then Google said after a future update they wouldn't support it any more. They were planning to push an update that outright removed functionality, and that functionality was in one of the few cutting edge areas that was really taking off at the time, too.

And Firefox screwing up support for the plug-ins was just poor quality checking before a release. There's no excuse for breaking something on that kind of scale, particularly when the bug was already in the tracker several days before the update was pushed out.

Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.

No, they really don't. When my clients ask why the software they've paid me a lot of money to write for them has stopped working, with the result that their on-call guys are getting woken up in the middle of the night by someone on the far side of the world who can't use their very expensive equipment any more, the answer they are looking for is not "Well, you see, we use a Java applet in this product because when we started the project a few years ago HTML5 canvas didn't have the functionality, speed or portability we needed, and that Java applet requires that the user have a Java runtime installed on their system and a corresponding plug-in for their browser, and your customers are using Firefox as their browser, and Firefox pushes automatic updates, which in a stunning piece of incompetence your customers' system administrators have not disabled, so their key systems will apply the updates before anyone tests that nothing important breaks, and in one of those updates the Firefox developers kinda broke a bunch of things on pages that use applets, and that's why the users can't type text where they should be able to, and so it's really not our fault, but at least these bugs will probably get fixed in the next release and that probably won't be more than six weeks away, so for now your platinum support guys should tell your customers to just hang in there for some unknown length of time and then they'll be able to use that very expensive hardware again, and in any case I'm sure this won't in any way jeopardize that contract you were going to get to sell them another 250 units in a multi-million dollar deal next month." No, trust me, that's really not what paying clients want to hear at all.


It's a shame you don't have a reproducible test for the rendering issue in Chrome. Until you can reproduce it there's really no telling what is going on. Do you have any links to similar issues already reported? I'd be curious to read up on them.

The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners

Any test cases for this? It really is important to see a simple test case. I've never had any issues with either Chrome or FF with corners.

Sure h.264 is a mess. If it bothers you then don't use it. The fact is that Flash is still defacto standard for video, so for consumer facing pages that's probably what you should use.

Sounds like you're upset because you got burned by a recent issues with firefox. It's reasonable to expect such a big breaking change to be caught in their regression testing. Unfortunately it slipped through. The reality is that software has bugs. All software. Yours, and mine. Every product ever shipped has gone out the door with bugs. It's unpleasant, especially when you have no control over the fix.

Seems to me that a rapid release cycle actually works in your favour. Certainly better than the MS cycle where you can expect to have to live with bugs for 18month-2years between releases. Auto updating in particular is a boon for developers. If you look at the Chrome version stats, most people are on the latest stable build and this is mostly due to auto update.

Compare the difference between the graphs for IE and for Chrome under 'Version Adoption': http://arstechnica.com/business/news/2012/04/internet-explor...

Also, if you're developing an app which is actually used for 'multimillion $ deals' then why aren't you distributing it as an application inside of some kind of wrapper such as Qt? Sounds like deploying as a regular web app was a bad technical choice for you product.


Apologies for the brief response; I have to get to work shortly.

For the Chrome/dialog bugs, if you search for things like "chrome bug repaint" you'll probably find quite a few similar issues.

For the rounded corners bugs, this looks relevant:


As far as video goes, Flash is not the de facto standard any more if you're working with mobile. Apple won that one. And H.264 is technically superior to the other useful formats for HTML5 video and the only format supported and/or supported with hardware acceleration on several platforms, so dropping it isn't much of an option.

Finally, on the subject of testing, it wasn't really me personally who got burned by the Firefox screw-up, it was one of my clients. Their technical people understand that there isn't much I can do about it, but that doesn't help their customer support people who have to deal with irate customers.

In any case, we actually recommend that their customers use IE rather than Firefox or Chrome these days, because for all its sins, it is a stable platform to build on and we can test against it with some confidence that end users will see similar behaviour for a useful period of time to come. No-one connected with this project likes rapid browser release cycles: not the developers, not the users, and certainly not the guys paying my invoices, who are on the wrong side of both.


I was starting to feel some burnout a week ago after a couple of months of 10+ hour days 6 days a week. Refurbishing my roof worked wonders for me. Spending 3 days pressure cleaning, replacing tiles and painting did wonders for me. Obviously not the kind of advice that applies to everyone but it worked for me. Plus my roof looks great now :)


I don't want to offend you, but from all I understand about the burnout syndrome it's hard to 'feel some burnout' (either you crash or not. Struggling with work/life is a different thing) and next to impossible to get back on track in 3 days, whatever those involve.

Good that it helped you and I second the advice of stepping away from the machine and doing something involving manual labor.


No offence taken. Sounds like burnout was the wrong term to use. Maybe I staved off actual burnout from developing later on by taking this time off. Either way some manual labour felt good :)


A few people have mentioned information density as being important. I've got the 'Stylish' chrome extension installed with a userstyle for hn which looks like this:

table > tbody > tr:nth-child(3) > td{-webkit-column-count: 2; }

2 column layout is v.cool. Makes the front page as well as the comments section much more readable for me.

example: http://imgur.com/a/oidEM#1


It is easier for a user to scroll down a long continuous list than to hop back and forth between two columns. This is particularly true for ordered lists (as is the case with HN).

The only thing I strongly dislike about HN's current design is that comment line lengths are far too long[1].

[1] http://baymard.com/blog/line-length-readability


It reads like a newspaper. You read one column at a time. No hopping between columns.


How was the original author acting entitled? He's merely saying that instead of insulting his intelligence just give him some screenshots and info about your app in the noscript. If your app is worth it he'll flick the js switch to the on position.


That's an important question to answer. Creating a site that works sans js then layering on js is great, but it does entail duplication of effort, a larger testing burden etc. It's important to work out if the ROI for going the extra mile makes good business sense. Especially given the (excellent) point the original post makes: if a user has turned off js then if your app is worth their time they'll find the js switch again without difficulties.


Not saying that it isn't an important question but if the site doesn't work without js the user will most certainly not enable it just to decide whether the app/site is worth their time.

The instant the site fails the decision has been made.

If your site breaks without js you must at least realize that you will, at the very least, annoy the users who has actively disabled it.


People who look for trouble are apt to find it.

Next, you would have to build a cookieless site, avoid Flash and other annoying videos, fly blind without tracking etc.

/NoScript user /I am the 1 percent


You say that like its a bad thing! Actually sounds pretty good to me :-) seriously, when building a trite, shouldn't that be th first thing you do, then layer that stuff on top? Sounds like it would actually be easier to test!


> avoid Flash and other annoying videos

I can't think of a single reason why that would be a bad thing.


Are we talking about applications, or webpages? Of course an application written in javascript won't work without, that is a given. That's not the problem though, its static webpages (or what could be). If I get to a website with visible content (mainly text, or images), but isn't fully functional without javascript, I probably won't enable it. If I see one where I can't see content, I'll probably enable javascript there as well, but it depends if I want to read it.

Good examples of some problems I've seen are Twitter taking several seconds to load content, even when the javascript is cached (somehow facebook does it fast enough). You even have a webpage like this "http://www.html5rocks.com/en/tutorials/internals/howbrowsers...? that seems laggy when scrolling with js.


the problem isn't whether ie10 is good or not. It's that microsoft's update schedule runs at a glacial pace compared to chrome and firefox, both of which are on a 6 week(!!) rolling release schedule. Compare that to IE where literally years can go by between releases.

I really don't get why MS don't fork their browser into corporate and consumer versions. Let the corporate users run on ie6/7 or whatever legacy crap they need and let the rest of the web move at a reasonable pace.

Anyway that's where I think the hostility to IE is coming from.


Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in.

I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessarily match my own way of doing things).

Had the same experience with cakephp. All those freebies which eventually caught up with me.

Ties in well with the whole libraries vs frameworks debate. I'm now in the libraries camp.

I wonder if Meteor packages are decoupled from each other so that I can pick and choose which ones I'd like to use in my project.

Turns out there really is no such thing as a free lunch.


> I now need to buy-in to the entire (framework) mindset to progress which slows things down

That's interesting, that idea could be folded into the technical debt metaphor.

So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how it works, or you throw the whole thing out and use a different library.


Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and were inflexible black boxes.


I have to say that I feel like Rails' ORM does a magnificent job of saving me time. Migrations allow me to write database changes that can be undone more easily.

An ORM also seems to lower the amount of configuration it takes to get development databases synced. It's not as much of an issue for an experienced dev, but a designer or new team member would need help.

I have had to learn AREL, the relational algebra used by ActiveRecord, in order to do more advanced queries. That's analogous to learning SQL in more detail, but I'd still take that in a heartbeat over writing raw SQL. The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.


I've not used the Rails ORM so I can't comment on how good it is or how easy it is to debug queries (peer behind the magic).

*The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.'

Maybe it depends on the system you're working on however mitigating syntax errors seems like a small benefit. For me the SQL for most projects is fairly static i.e. once a given set of queries has been defined and tested they can lie there untouched, so once I nail a query and it performs the way I like I hardly ever need to go back and touch it again. However the performance penalty of sitting behind an ORM is ever present, for each query (at least for a cache miss). Personally I just don't like having 100s of lines of code sitting between:

model->get(('model.field' => 'value'));

and actually receiving the data.

It just seems so.... unnecessary.

of course YMMV, and perhaps the benefits kick in when you're working in a team (I'm not).


great point! i like to share this previous experience. years ago while working in large os development teams my approach was it was not enough to write tools/automate such that less experienced folks could perform tasks that had usually been done by senior folks -- the implementation had to empower the folks with less experience to control their own destiny -- which meant simplifying the implementation to the extreme. This also empowered the senior folks too as often the tools are not a primary focus, they just want to get some done and on with it


Awesome! Must be such an amazing feeling to receive that first payment. I'm about a month away from my first launch and I'm terrified of launching and then hearing.... crickets. So congrats to you!

Had a look at the product. Looks v.solid. Just a couple of things:

- When I attach a file via /projects/project_name/stories/ it completes the upload then the files seems to disappear? What I mean is that the progress indicator goes to 100% and nothing else happens. Then if I go back to root and back to stories there is no file.

- I think you need labels on the 4 symbols on the left hand side. The only one which is self evident is the '?'. The others I have to hover over to find out about and that is annoying from a UX pov.

Cheers and good luck :)


Thanks for the feedback!

To attach a file, you need to also comment (I realize now this might not always be ideal). But the workflow would be: Attach some files, enter text in the comment box, post. I'm working on redesigning the entire task detail page, which will hopefully make this less confusing.

I agree. I'm trying to figure out a good way to make this more evident without widening that left sidebar. This is the current UX problem that's keeping me up at night :-)

Thanks again, I really appreciate your feedback!



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact