(since find |wc -l would miscount files with newlines in the name)
I gotta ask... How many files do you have with newlines in the name? And what kind of masochist puts newlines in a filename in the first place?;-)
Just one filename containing a newline is enough to make the simpler command give the wrong answer. And I've never heard of a Unix system where a single person (other than Ken Thompson, maybe) chose the name of every file on the system.
I try to make as few assumptions as possible in the programs I write, because if I do make an assumption I can be sure that it's likely to eventually bite me.
I had thought that tab-completion for filenames does not occur after #, but as things turn out I'm wrong. No idea if that is a recent change to Bash or not, though.
You can get the C++ standard in book form (and the C standard) from Prentice-Hall. But a version you can grep is even better.
The advice about learning your editor well (whatever it is) is essential too. I've watched VI users waste hours because they don't know about the %s command and aren't interested in learning.
As for TCP/IP, the problem with reading the RFCs is that often the best introduction to a topic is RFC 103 but 63% of that was superceded by RFCs 21897 and 11238474. Lots of the RFCs are short, to the point, and well written, but still I would suggest that the best intro to TCP/IP is "TCP/IP Illustrated, Vol. 1" by Stevens. In fact you would not be going far wrong by just reading everything that W. Richard Stevens wrote.
The skim reading tip is good too - I basically learned Unix by reading a copy of the HP-UX man-pages from A to Z. I learned a lot about the Ada compiler before I found out it wasn't installed, but the end effect was that I could usually remember the name of the command that did what I wanted.
First, in order to become a good programmer, you should expect to read about one hundred times more code than you write (in terms of finished code). Read both your colleagues' work and code from elsewhere (open source stuff, stuff in books, etc.).
When you are reading a program, try to decide if it is good code or bad code. If it's bad code, decide why. As you start to move beyond "well, it's not done the way I would do it", then you will be in a place where you can learn new ideas and techniques just from reading somebody else's code. When you see code you think is bad or even just hard to read, decide why and figure out how to avoid doing that yourself.
There are a lot of second-rate programmers in the world. They get that way by avoiding the chance to learn from other people, and through not learning from their own mistakes. Try to set your work up so that you do learn from your own mistakes. For example, eventually one of your colleagues will find a bug in code you wrote. If at all possible, fix it yourself. Then go look for similar cases in the rest of your code. If they don't want to give your he bug to fix, ask them to explain what you did wrong and how you can avoid doing it again. Once of the best experiences in my programming life was doing this for a couple of years while working on a life-critical system. I learned a lot about how to write better code, and how to write programs so that the compiler catches the bugs for me.
You should read some books that will give you ideas about how to think about program designs, approaches and how to approach the nuts and bolts of the field. However, the best reading list depends quite a bit on your chosen language. Here's a rough list (slanted towards C and Java, so if that's not your bag other books may be better choices):
Programming Pearls - Jon Bentley
The Practice of Programming - Kernighan + Pike
Writing Solid Code - Steve Maguire (or Code Complete I guess)
Design Patterns - Gamma, Helm, Johnson, Vlissides
These are also good but are more narrowly focussed:
Effective Java - Joshua Block Effective C++ -
Scott Meyers Refactoring: Improving the Design of Existing Code - Fowler, Beck,...
I would also suggest that you make a to-do list of things to learn or find out about. A big item on there should be to expose yourself to a small number of programming languages that differ quite a lot from the language you mainly use at work. An example of such a diverse set of languages might be: Visual Basic, Java, C, a scripting language (e.g. Python or Perl), LISP, and a functional language (e.g. Haskell or ML). The idea here is to squish your brain into a configuration where you can think about your existing problems in terms of a selection of programming paradigms.
If you are lucky your employer will recognise the need for everybody to get better at their job and help pay for these books. My earlier employer didn't, but I made a habit of buying a good book every month or so and reading it. I'm a better programmer for it. My current employer pays for books, but I find I buy different kinds of books for home and work (e.g. at work I bought "Python in a Nutshell" and at home I recently bought a stack of compiler books).
Some of the handouts make the problem worse in some ways.
By US law, food aid given by the USA must be bought from US producers. Even once shipped to the country being helped, the aid food often undercuts local supplies of food. This results in collapses in local markets, making the situation worse (or at least making it persist).
Check web for partially-sighted people's orgs
on
Cell Phone For the Blind?
·
· Score: 5, Informative
Why not just refer to information from some local organisation of blind people? There's this survey of accessible mobile phones in the UK, but surely there must be something similar for the USA.
My hardware identifies traffic streams as 'Interactive', 'Download', and 'Bulk Download'. 'Interactive' is the obvious ssh, rdp, etc traffic. 'Download' is for stuff I want sooner rather than later, 'Bulk Download' is for stuff that I don't necessarily want so fast (eg torrents).
This technology has existed in IP itself since 1981 as the TOS bits. Your "Interactive" is IPTOS_LOWDELAY. Your "Download" is IPTOS_THROUGHPUT. Your "Bulk Download" is IPTOS_LOWCOST. See RFC 791 from 1981 and RFC 1349 from 1992.
They were just missing a good excuse to hate the US
Really? Perhaps you had some special instrument that allowed you to see other people's future thoughts.
(I mean, lets face it, it was the US picking up most of the tab for the DISASTER the Europeans caused in AFRICA... but I digress).
That's a multilateral disaster. Just look at the US's policy on AIDS in Africa. Not to mention the US payment arrears.
Before 9/11 Europeans just called us "fat and ugly", now they can call us "warmongerer's".
Actually they call you warmongers, because they can spell. Of course they are talking about the government of the USA, not its people.
Which is Ironic considering that the worse humanitarian disaster in the history of humanity was caused exclusively by Europeans (WWI and WWII).
You mean "worst", not "worse". They mean different things. Anyway, there are lots of huge humanitarian disasters to choose from, it is hard to find objective measurement criteria. I would also suggest that there are lots of other examples too (for example this one).
Its just plain bat shit silly that the world doesnt hate Europe as much as they hate the US. Lets face it, 90% of the worlds problems today is caused by the actions of EU nations circa 1600-1900. (mostly before the creation of the US, and before the US became a real world player)
A lot of it is about the perception of arrogance. The US is perceived that way now, but before that (in reverse chronological order) it was the UK, France, and before that I guess the Roman Empire (there's a big gap there for the Middle and Dark ages, but my world history for those times is a bit weak).
Either upgrade to a lighter laptop (yes, the lighter ones are punier and yet they are more expensive) or tote just a USB drive and ask your hosts to provide a laptop to run the presentation from the USB stick. I suppose you could use web-based presentation software, but that still requires you to use somebody else's machine.
What do you mean "would work"? It's been working for a long time. The British did this thirty years ago. I'm sure there are other similar systems elsewhere in the world, too.
The two main problems with these schemes are that the capacity is quite limited - you run out of water in the high-altitude reservoir - and getting the response time down to small numbers of seconds requires energy input (you can't just let all the water in at once with the turbines stationary, since that would damage the bearings, so if you want fast response you have to spin the turbines up on compressed air).
Of course, such schemes won't work everywhere either. Countries like Holland don't have enough mountains for this to work well, and countries like the USA do have mountains, but the transmission losses between those and the centres of population are larger than is the case in a small country like the UK.
Honestly I'm not the best person to ask about that. But if I were choosing one without external help, I'd start by reading the Koopman paper. However, it contains no implementations AFAIK.
I've seen Adler-32 fail twice, so your assumption of "a few times per millennium" doesn't seem to work for me (I'm under 40). In fact in those cases it was even stacked on top of at least one other checksum mechanism, too.
One of the problems with it is poor spreading of the input bits into s2. There are other algorithms which don't have that weakness but don't (IIRC) cost any more to compute.
I try never to comment on Google stories but this comment shines forth as being so glaringly dismissive that I can't hold back. If you think that going from 1e9 to 1e12 known URLs is not "an impressive conceptual or technical feat" you should review some course materials on asymptotic complexity and think about how you would index the entire web using only algorithms that don't simply become infeasible at 1e12. In fact, forget about the indexing complexity per se, have a think about how you would select which subset of the 1e12 URLs to actually index. That's a hard problem in itself.
Sounds like the guy is a net drag on your team.
It also sounds like your boss is either blind to the factors that make software teams effective or is so reluctant to have a difficult conversation that (s)he puts up with a woeful situation rather than fixing it.
Suggestion: implement test-based development. Have regression and unit tests for code. Implement a policy that commits breaking the build will simply be rolled back by the "build cop" (ideally it's best if someone else is the build cop since this defuses the interpersonal aspect of the issue).
From what you said, I would guess that the guy who doesn't commit frequently is going to find that all his giganto-commits are rolled back because they cause breakage. The pain of the poor practice is therefore felt by the person with the poor practice, not by everybody else. This will put pressure on them to improve their practice in order to meet their goals/deadlines/whatever.
Most CS literature is in English. I'm guessing you already know English. So if you want to study additional stuff, it won't have to be a language. Ideas for improving your earning potential include further algorithm analysis and suchlike (I'm not sure how far your Computer Engineering course goes in that). Alternatively you could study something related to a particular industry (quantitative analysis seems like a good bet).
But if you're set on working on a new language, I'd suggest Mandarin. The reason here is that it's the only language in which there is a large amount of computer-related material which is not available also in English. The material I'm talking about is data sheets. There are quite a few data sheets for hardware parts available in Mandarin but not English. (see for example the article about Chumby manufacture in China
Slashdot Mirror
That drops blank lines. You probably meant
grep '' .*
I haven't tested it, but it is possible that this is a more efficient way of doing that:
awk '{print FILENAME, $0;}' list-of-file-names
It's less time-consuming for me and more educational for you if you go figure it out by reading the manual :)
I gotta ask... How many files do you have with newlines in the name? And what kind of masochist puts newlines in a filename in the first place? ;-)
Just one filename containing a newline is enough to make the simpler command give the wrong answer. And I've never heard of a Unix system where a single person (other than Ken Thompson, maybe) chose the name of every file on the system.
I try to make as few assumptions as possible in the programs I write, because if I do make an assumption I can be sure that it's likely to eventually bite me.
I had thought that tab-completion for filenames does not occur after #, but as things turn out I'm wrong. No idea if that is a recent change to Bash or not, though.
Your first command would be much more efficient as
find . -exec grep -ql blah {} \+
(I added the regex for you)
Assuming you already know the simple stuff like how to use shell quotes correctly, what you can do with ps and top, ...
This is all great advice.
You can get the C++ standard in book form (and the C standard) from Prentice-Hall. But a version you can grep is even better.
The advice about learning your editor well (whatever it is) is essential too. I've watched VI users waste hours because they don't know about the %s command and aren't interested in learning.
As for TCP/IP, the problem with reading the RFCs is that often the best introduction to a topic is RFC 103 but 63% of that was superceded by RFCs 21897 and 11238474. Lots of the RFCs are short, to the point, and well written, but still I would suggest that the best intro to TCP/IP is "TCP/IP Illustrated, Vol. 1" by Stevens. In fact you would not be going far wrong by just reading everything that W. Richard Stevens wrote.
The skim reading tip is good too - I basically learned Unix by reading a copy of the HP-UX man-pages from A to Z. I learned a lot about the Ada compiler before I found out it wasn't installed, but the end effect was that I could usually remember the name of the command that did what I wanted.
First, in order to become a good programmer, you should expect to read about one hundred times more code than you write (in terms of finished code). Read both your colleagues' work and code from elsewhere (open source stuff, stuff in books, etc.).
When you are reading a program, try to decide if it is good code or bad code. If it's bad code, decide why. As you start to move beyond "well, it's not done the way I would do it", then you will be in a place where you can learn new ideas and techniques just from reading somebody else's code. When you see code you think is bad or even just hard to read, decide why and figure out how to avoid doing that yourself.
There are a lot of second-rate programmers in the world. They get that way by avoiding the chance to learn from other people, and through not learning from their own mistakes. Try to set your work up so that you do learn from your own mistakes. For example, eventually one of your colleagues will find a bug in code you wrote. If at all possible, fix it yourself. Then go look for similar cases in the rest of your code. If they don't want to give your he bug to fix, ask them to explain what you did wrong and how you can avoid doing it again. Once of the best experiences in my programming life was doing this for a couple of years while working on a life-critical system. I learned a lot about how to write better code, and how to write programs so that the compiler catches the bugs for me.
You should read some books that will give you ideas about how to think about program designs, approaches and how to approach the nuts and bolts of the field. However, the best reading list depends quite a bit on your chosen language. Here's a rough list (slanted towards C and Java, so if that's not your bag other books may be better choices):
These are also good but are more narrowly focussed:
I would also suggest that you make a to-do list of things to learn or find out about. A big item on there should be to expose yourself to a small number of programming languages that differ quite a lot from the language you mainly use at work. An example of such a diverse set of languages might be: Visual Basic, Java, C, a scripting language (e.g. Python or Perl), LISP, and a functional language (e.g. Haskell or ML). The idea here is to squish your brain into a configuration where you can think about your existing problems in terms of a selection of programming paradigms.
If you are lucky your employer will recognise the need for everybody to get better at their job and help pay for these books. My earlier employer didn't, but I made a habit of buying a good book every month or so and reading it. I'm a better programmer for it. My current employer pays for books, but I find I buy different kinds of books for home and work (e.g. at work I bought "Python in a Nutshell" and at home I recently bought a stack of compiler books).
So, this is the end for the Mentos® + Diet Coke® videos then?
Some of the handouts make the problem worse in some ways.
By US law, food aid given by the USA must be bought from US producers. Even once shipped to the country being helped, the aid food often undercuts local supplies of food. This results in collapses in local markets, making the situation worse (or at least making it persist).
Why not just refer to information from some local organisation of blind people? There's this survey of accessible mobile phones in the UK, but surely there must be something similar for the USA.
This technology has existed in IP itself since 1981 as the TOS bits. Your "Interactive" is IPTOS_LOWDELAY. Your "Download" is IPTOS_THROUGHPUT. Your "Bulk Download" is IPTOS_LOWCOST. See RFC 791 from 1981 and RFC 1349 from 1992.
They were just missing a good excuse to hate the US
Really? Perhaps you had some special instrument that allowed you to see other people's future thoughts.
(I mean, lets face it, it was the US picking up most of the tab for the DISASTER the Europeans caused in AFRICA... but I digress).
That's a multilateral disaster. Just look at the US's policy on AIDS in Africa. Not to mention the US payment arrears.
Before 9/11 Europeans just called us "fat and ugly", now they can call us "warmongerer's".
Actually they call you warmongers, because they can spell. Of course they are talking about the government of the USA, not its people.
Which is Ironic considering that the worse humanitarian disaster in the history of humanity was caused exclusively by Europeans (WWI and WWII).
You mean "worst", not "worse". They mean different things. Anyway, there are lots of huge humanitarian disasters to choose from, it is hard to find objective measurement criteria. I would also suggest that there are lots of other examples too (for example this one).
Its just plain bat shit silly that the world doesnt hate Europe as much as they hate the US. Lets face it, 90% of the worlds problems today is caused by the actions of EU nations circa 1600-1900. (mostly before the creation of the US, and before the US became a real world player)
A lot of it is about the perception of arrogance. The US is perceived that way now, but before that (in reverse chronological order) it was the UK, France, and before that I guess the Roman Empire (there's a big gap there for the Middle and Dark ages, but my world history for those times is a bit weak).
Forget drainage, you need a hole in the wall to let out the hot air that the air conditioner produces as waste.
Either upgrade to a lighter laptop (yes, the lighter ones are punier and yet they are more expensive) or tote just a USB drive and ask your hosts to provide a laptop to run the presentation from the USB stick. I suppose you could use web-based presentation software, but that still requires you to use somebody else's machine.
What do you mean "would work"? It's been working for a long time. The British did this thirty years ago. I'm sure there are other similar systems elsewhere in the world, too.
The two main problems with these schemes are that the capacity is quite limited - you run out of water in the high-altitude reservoir - and getting the response time down to small numbers of seconds requires energy input (you can't just let all the water in at once with the turbines stationary, since that would damage the bearings, so if you want fast response you have to spin the turbines up on compressed air).
Of course, such schemes won't work everywhere either. Countries like Holland don't have enough mountains for this to work well, and countries like the USA do have mountains, but the transmission losses between those and the centres of population are larger than is the case in a small country like the UK.
Honestly I'm not the best person to ask about that. But if I were choosing one without external help, I'd start by reading the Koopman paper. However, it contains no implementations AFAIK.
I've seen Adler-32 fail twice, so your assumption of "a few times per millennium" doesn't seem to work for me (I'm under 40). In fact in those cases it was even stacked on top of at least one other checksum mechanism, too.
One of the problems with it is poor spreading of the input bits into s2. There are other algorithms which don't have that weakness but don't (IIRC) cost any more to compute.
Adler-32 wouldn't be a great choice. It's fast but it's weak for short messages and I've seen it fooled by multi-bit errors on large messages too.
See Koopman's paper 32-bit cyclic redundancy codes for Internet applications for some better ideas.
Anyway, would have, not would of. Sheesh.
I try never to comment on Google stories but this comment shines forth as being so glaringly dismissive that I can't hold back. If you think that going from 1e9 to 1e12 known URLs is not "an impressive conceptual or technical feat" you should review some course materials on asymptotic complexity and think about how you would index the entire web using only algorithms that don't simply become infeasible at 1e12. In fact, forget about the indexing complexity per se, have a think about how you would select which subset of the 1e12 URLs to actually index. That's a hard problem in itself.
Yuck. Much more efficient: find . -name 'a*' -ls
Sounds like the guy is a net drag on your team. It also sounds like your boss is either blind to the factors that make software teams effective or is so reluctant to have a difficult conversation that (s)he puts up with a woeful situation rather than fixing it.
Suggestion: implement test-based development. Have regression and unit tests for code. Implement a policy that commits breaking the build will simply be rolled back by the "build cop" (ideally it's best if someone else is the build cop since this defuses the interpersonal aspect of the issue). From what you said, I would guess that the guy who doesn't commit frequently is going to find that all his giganto-commits are rolled back because they cause breakage. The pain of the poor practice is therefore felt by the person with the poor practice, not by everybody else. This will put pressure on them to improve their practice in order to meet their goals/deadlines/whatever.
But if you're set on working on a new language, I'd suggest Mandarin. The reason here is that it's the only language in which there is a large amount of computer-related material which is not available also in English. The material I'm talking about is data sheets. There are quite a few data sheets for hardware parts available in Mandarin but not English. (see for example the article about Chumby manufacture in China
Your witty put-down would have carried more sting if you could actually spell.