Hacker Newsnew | comments | show | ask | jobs | submit | VBprogrammer's commentslogin

While in terms of reliability, simplicity and power to weight ratios turbine engines are great, they still suffer from low compression ratios.

If I remember correctly about 3 to 1, compared to 10 in 1 for petrol engines and nearly 20 to 1 for diesel engines.

Thermodynamically this makes it very difficult to achieve high efficiency.

reply

StillBored 9 days ago | link

"If I remember correctly about 3 to 1,"

That seemed strange to me given multistage compressors. Maybe 3:1 is true for a micro turbines, but for larger jets wikipedia says the pressure ratio is 30:1 to 40:1 citing the Trent 900 at 39:1 and the GE90 at 42:1.

Which according to the same article says that a 40:1 PR is equivalent to a 15:1 compression ratio.

http://en.wikipedia.org/wiki/Overall_pressure_ratio

reply

VBprogrammer 9 days ago | link

I stand corrected. I'm sure I had read that some time ago but I can't find a reference at the moment.

reply


> Good, descriptive commit messages

All of the examples given in the image going that heading I'd say are mediocre at best.

The code changes should tell you what has changed, if I'm looking back through your commit history what I'm usually trying figure out is why you've changed something.

A ticket number is often the single most useful thing, ideally followed why a very brief what you've changed and as much information on why you've changed it as you think would be useful.

-----

VBprogrammer 36 days ago | link

As an example of what I'd like to read:

  #2313 Change expected value to a float field.

  django-haystack stores decimal fields as strings internally.
  This means that when we order by expected value small
  values (e.g '9e-08') are sorted before larger values.

-----

babuskov 36 days ago | link

I prefer to keep such comments in the code, not in the commit message. It is highly unlikely that anyone coming to do some changes to that part of the code would go and read a year-old commit message that he isn't even aware exists.

-----

why-el 36 days ago | link

There is a difference tough, a very subtle one. A commit body should describe the rationale of the change, i.e. any decisions that had to be made or trade-offs in light of developer discussions and so on. Basically a description of the issue being solved. These things are rarely needed in the code itself, as the code will most likely feature new things and the old things are history.

Some commits even feature implementation details, and those I agree with you sometimes it makes sense to include them in the code. However most implementation details replace old ones, and this is transition should be explained in a commit since this is the perfect place for it.

Here is an random example from the linux kernel, which is guaranteed to do what I described: http://goo.gl/QdKNnJ

-----

VBprogrammer 36 days ago | link

The example I gave (happened to be what I was working on) would be quite pointless as a comment. Since the code could easily have been written using the float datatype.

-----

pretzel 36 days ago | link

Try using git blame. It tells you what change caused a line to happen. I often use it to find out exactly what issue caused a seemingly crazy bit of code to happen. As the code goes away, so does the commit message - not necessarily so with a comment.

-----

tomswartz07 36 days ago | link

While that's true; `git pickaxe` will also do what you describe. The added bonus is that one could use pickaxe to follow a specific line's changes way farther back than a normal comment.

http://jfire.io/blog/2012/03/07/code-archaeology-with-git/

-----

u801e 36 days ago | link

You can run git blame to get the information pertaining to that particular line of code. That's a really good way to document what a particular piece of code is doing and why at the time it was written.

-----

ukd1 36 days ago | link

This is a great example - it's details, explains the issue and also has the bug id (presumably) in it.

-----

Smudge 36 days ago | link

You're right -- the diff answers the what, so being able to answer the why concisely is what makes a good commit message.

Ticket numbers are important context, but unless it is a one-off commit you can instead put that info in the merge commit (as if saying, all of these commits I'm merging were made as part of fixing Issue #17).

Some people like to use squash extensively for that reason, but then you don't have the same granularity when it comes to reverting individual bits of that commit without reverting the entire bugfix. (This assumes that every commit leaves the code in a working state with passing tests).

-----

erichurkman 36 days ago | link

Issue numbers in each commit can also help when you end up cherry-picking commits from one branch to another.

-----

Smudge 36 days ago | link

I guess in that scenario my preference would be to amend the cherry-picked commit's message to include why it was cherry-picked.

The alternative in your case (leaving it as-is, with an issue number) implies that the entire commit addresses that particular issue number, which may not be true. (It may be part of a series of commits for that issue)

-----

reledi 36 days ago | link

This creates a lot of noise on GitHub though. I prefer to put the issue number in the branch name and in the PR description. But for one-off commits, it goes in the commit message.

-----

VBprogrammer 36 days ago | link

Yeah, I prefer the issue number in each commit as it makes the commit log more readable to me. But do a decent job of everything else and that is a very small nit-pick.

-----

jipiboily 36 days ago | link

I agree it useful, but it's more useful overtime than anything, on the short term, issue numbers are not really useful. You are right, those examples were not our best ones ;)

-----

smathieu 36 days ago | link

I think the point was mostly that 'lol' or 'meh' is a completely useless comment. It's true that there's a lot of room for improvements in the given example. Still, they do provide some context to people who actually understand the application they are working on.

Does anyone know of good open source project that uses Git messages extremely well that we could use as an example?

-----

KajMagnus 36 days ago | link

Yes, Git itself :-) git://git.kernel.org/pub/scm/git/git.git and https://github.com/git/git

Git's commit log is probably the most detailed and informative log I've ever seen. And it's a bit fun to have a glance at Linus Torvald's old initial commits from 2005 :-)

(You might want to check the 'pu' branch rather than the 'master' branch. And there're lots of 'Merge branch...' commits that aren't super interesting.)

-----

VBprogrammer 36 days ago | link

Yes, they are clearly vastly superior to 'lol', 'meh' or worse 'fix'. Still, I think my point stands that they could be better.

-----

jipiboily 36 days ago | link

Yes, totally! We picked some examples quickly just to demonstrate that people can do better "lol", "fix" or "meh". There is still room for improvements and we have better ones, too.

-----

tomswartz07 36 days ago | link

Not to toot my own horn, but I have a few minor projects that I try to meticulously document with the git commit messages.

https://github.com/tomswartz07/linux-configs/commit/3684d3ad... is an example of one.

-----

tomswartz07 36 days ago | link

One of my biggest pet peeves is poorly formatted commit messages.

I have one coworker who continually fails to put the empty line between the first line and the body of the commit message. So many of our git logs are littered with 100+ character long messages.

The other commenters hit the nail on the head with the fomatting. Short, precise, and properly formatted.

-----

babuskov 36 days ago | link

We had an interesting policy in the company where I worked before and I use it for my own projects: only one line is ever allowed - explaining WHAT was changed.

- to explain HOW it works: comment in the code, so whoever comes to change the code later knows what should be touched and what should be left alone

- to explain WHY it was changed, use the bug tracker and just supply the #ID of bug/feature request in the comment

Having single-line comments makes it much easier to browse through history and find the thing you're looking for.

-----

tomswartz07 36 days ago | link

I totally agree- That sounds like a wonderful policy to have.

Unfortunately, the powers-that-be aren't too keen on enforcing something like that in our current projects.

-----

alwillis 36 days ago | link

This is probably more on point--"A Note About Git Commit Messages” http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa...

-----


  The Data Protection Act

  Under the Data Protection Act, we have a legal duty to protect any information we collect from you. We use encryption software to safeguard your data, and keep strict security standards to prevent any unauthorised access to it.
I'm lost for words.

-----


I find when I have to re-factor code around the tests it means the code wasn't very good in the first place.

The author complains about re-factoring code into smaller testable functions. I completely disagree. Code structured as small easily understood functions which do one thing and have obvious inputs and outputs is good code which is much easier to extend and modify.

-----

emn13 127 days ago | link

Yeah, that's one of the article's weaker spots. But as a rule, I'd tend to interpret imprecise statements like that charitably. He's not saying that small, clear functions are bad, but that splitting functions for the purposes of testing is counterproductive. He's not saying anything about splitting for clarity and focus.

-----


Someone I used to work with once left a alert('W.A.N.K') in the codebase. This was in a fairly rarely occurring branch of code and made it all the way to production.

I've taken that as a warning and never write anything I wouldn't be happy for a customer to see in logs, test-data, comments (although handfuls of sarcasm are still acceptable) or debugging code.

-----

mootothemax 137 days ago | link

I've taken that as a warning and never write anything I wouldn't be happy for a customer to see in logs, test-data, comments (although handfuls of sarcasm are still acceptable) or debugging code.

Very good advice!

I once worked with someone who had the unfortunate habit of naming debugging log files "shit".

After a server migration, a couple of paths had been incorrectly set, leading to the client complaining about a now-memorable error: "Cannot open: shit".

Whoops

-----

hcarvalhoalves 137 days ago | link

> "Cannot open: shit".

I'm adopting this error message for I/O from now on.

-----

philbarr 137 days ago | link

I worked on some software that automatically generated documentation for engineers. During testing someone put "hello fuckers" in the code so that he could easily see when it came out the other end.

Naturally that code was left in and went into production, and the customer rings up to complain they'd just printed out a 2000 page manual with "hello fuckers" at the end of every line.

I've never seen a manager look so furious, but we were all paid so little we just laughed.

-----

gcb0 137 days ago | link

> but we were all paid so little we just laughed.

that summarizes the whole thread.

-----

tripzilch 136 days ago | link

This. I didn't even need to learn this the hard way, just had to read back some of my earliest teenage code (obviously not for any type of "production" setting) and hear enough of these scary stories to decide once and for all, it's really not that hard or big of a deal to be professional about these kinds of things.

Same goes for code comments. Unless it's a really, really good joke that won't offend if it happens to show up anywhere, or over your shoulder.

-----

venomsnake 137 days ago | link

I was officially forbidden in my old job to write error messages at 3AM. Code was ok. But text - not after а high ranking client saw an error message. Its good that during the meetings with him we both were (in)appropriately vulgar and offensive so only my manager was shocked.

-----


Or a hack which will never be removed from the code-base, depending on your point of view.

I'm intrigued as to why changing to relative domains wasn't possible. If nothing else pushing 'http://www.theguardian.com' out for every link adds to a lot of bytes up for a busy site.

-----

cbr 143 days ago | link

    pushing 'http://www.theguardian.com' out for every link
    adds to a lot of bytes up for a busy site
Fewer than you'd think after gzip compression:

    $ curl -s http://www.theguardian.com/us | wc -c
    223195
    $ curl -s http://www.theguardian.com/us | \
       sed s'~http://www.theguardian.com~~' | wc -c
    215473
    $ curl -s http://www.theguardian.com/us | \
       gzip | wc -c
    33783
    $ curl -s http://www.theguardian.com/us | \
       sed s'~http://www.theguardian.com~~' | gzip | wc -c
    33554
They have 7.7k of extra html due to repeating "http://www.theguardian.com" for every link, but gzip compressed this is only a difference of 229 bytes.

-----


I'd be willing to bet that the article was written on the 11th or even before that. The campaign started with a nearly impossible goal, unless Obama himself had come out to declare surrender, they were always going to be able to print that.

-----


I know bringing things from the real world into the digital realm often results in badly overstretched metaphors. Allow me this one; are your belongings really yours if you forget to lock the door?

-----

sp332 148 days ago | link

It's not about ownership, it's about privacy. Yes, people are allowed to look at your stuff if you leave it in a public place.

Edit: it's even stronger in this case, because it's your own equipment that is providing the data to anyone who asks politely (using industry-standard requests and no impersonation or other fraud).

-----

Someone 148 days ago | link

But is your living room a public place, if you leave your front door open? I don't think so.

-----

sp332 148 days ago | link

But you're not in the living room. You asked for the data politely and the server sent the data to you. It even put your address on it to deliver it over the public internet.

-----

yeahbutbut 148 days ago | link

> Allow me this one; are your belongings really yours if you forget to lock the door?

Practically, it depends on where you live. In major urban areas: no they're gone and they probably aren't coming back. Insurance might replace some of them.

In the sticks? Most people don't lock their doors, even if they shut them.

> I know bringing things from the real world into the digital realm often results in badly overstretched metaphors.

Except this metaphor is already stretched beyond breaking. An index isn't even a copy.

Copying a set of publicly available read-only files is not theft (you still have your copy I haven't deprived you of it).

But we're not even talking about copying your files, just the names you've assigned to them. And in his proposed form, even allowing you to remove the names from our index.

Pretty kind treatment for a copy that you've given me when I asked for it.

-----

sneak 148 days ago | link

> forget to lock the door

oh god this again

-----

infinite8s 148 days ago | link

Your belongings are really only yours to the extent that social contract (ie the law) defines them as such or you are able to prevent other people from taking them. Everything else is an illusion.

-----


I'm pretty sure many more codebases have been lost through failures to secure internal networks by corporate IT departments than through vulnerabilities in cloud hosting providers.

-----

ProAm 154 days ago | link

I agree. I was speaking more about security than we blew up our own code repository. Everyone has the ability to light their own house on fire.

-----

Fogest 154 days ago | link

I think he is referring to many people failing to secure their networks and having code stolen. It can be just as insecure, if not worse than a cloud provider if done wrong.

-----


I'm not sure I fully understand your comment. My understanding of this is that even after the revised accounts the auditor was still unwilling to put his name on the line. The implication in my eyes is that the books are still in pretty bad shape and could be worse.

Is there some reading of this that I'm not getting?

-----

andyjohnson0 156 days ago | link

Thats the way I read it too.

-----

More

Guidelines | FAQ | Lists | Bookmarklet | DMCA | News News | Bugs and Feature Requests | Y Combinator | Apply | Library | Contact

Search: