Fast way to improve your English - the Black spot programme - hints for international students learning English

Another way to improve your English FAST is the black spot program:

It's simple:

Pick the 3 most common mistakes you make, and FIX them.

then

pick the 3 most common mistakes you make, and FIX them.

then

pick the 3 most common mistakes you make, and FIX them.

etc....

he he he :-)

For starters:

Get (ask nicely) someone to fix your English and CAREFULLY find out what mistake you make often. Then fix it !

By that I mean: work out what it should be, and why.

Then practice it, make sure it does NOT happen again.

Many times I fix student's English and the next time they give me some work to look at: SAME D**** mistakes... same problem with definite indefinite articles (e.g. 'a' VS 'the')

Example: from your own email below:

you write "...but there may be slightly different."

mistake: plural VS singular, the sentence should be (CAPS show changes):

"...but THEY may be slightly different."

or

"...but there may be slight--- differENCES."

Pick any of the essays that someone corrected and proof read for you, where 'Track Changes' has been used. Pretty quickly you will that one kind of mistake happens a LOT. Fix it, focus on it. Learn it.

If you don't understand the reasons, for the correct way, just memorize it till it becomes second nature and sooner or later the sense and feeling of the 'correct' language structure comes to you.

Dr Hyko,

here is a question about academic writing:

(1) as you said, you have to FEEL the language , as you studied a foreign language.

But when I am summarizing the academic articles, a foreigner liek me always have a question:

For the English words of similar meanings in Chinese, how to identify their differences?

As a Chinese, the meanings of "rubbish" , "trash" and "garbage" are the same, but there may be slightly different.



So are there any specific dictionaries explaining this kinds of words ?

Also, are there any good books teaching academic language fore foreigners ?

According to your part instruction to some Chinese engineering students.

G




Dear Mistress G,

Here are some suggestions:

Read LOTS, of books in English which INTEREST you...
That expands your vocabulary.

If not sure, about distinctions of rubbish, "rubbish" , "trash" and "garbbage",

pick a native speaker, ask them to explain, - this way you:

- get to meet more people

- experience more real life opinions.

- get an answer to your question that is up to date and real.

Books and dictionaries, are last on my list of useful tools :-P

H

Things you won't believe until you find out for yourself. - Heiko's guide to programming.

Just how hard can it be to write a program that plays a nice sounding chord every few minutes ?
Answer: no worries mate, do it in a day!!!

Real Answer: Well, not that easy. At least not as simple as I first thought. I wanted to make a program that would play the sound of a set of chimes every 15 minutes, like an old Grandfather clock, the program would be called: the TimeChime program.


When I started I expected it would be so simple I could finish the program in a day. That was mid 2007. Many interruptions later, it was finished in March 2008. In my own defence I should say that I don't program for a living, I teach it instead.



I found out that contrary to my optimistic and naïve assumptions you can’t just call a sound file and hope it will run and exit nicely. No no no !!! I needed to figure out how to call another program from my TimeChime program and make it do what I wanted it to. That took a lot of time and didn’t always work, the whole show would often just ‘hang’.



That’s when I found out that ‘pipes’ were a lot better than ‘system calls’ and that running the whole process in a second thread gave me a really neat way to kill any processes that didn’t toe the line (“There iz only ONE Way, and zat is my vay”).

Using the good old ‘try – catch’ pair helped a LOT as well. All of those fairly advanced techniques were required just to make a program that played a couple of sound files every 15 minutes. I had no idea it was that complicated when I started.
In the process I learnt a lot, or rather I remembered a lot from my programming days which I had forgotten. I learnt all the old lessons again.


Lesson 1: NO Theory please we've got to get some real work done ! I realized (again) that when you write software for a living you don't read theory, at least I don't. I don't go to lectures run by people like myself teaching about programming.
I don't read manuals and I certainly can't even begin to make sense of those Microsoft data pages on what or how to use a function or API.
Instead what I do first is search for anything and everything that is in any way similar to what I want to do.
Then I copy their code. Yes, I copy ! Now don't get me wrong, its not copying large chunks of code and passing them off as my own, - large chunks of code are called 'libraries' and everyone uses them all the time.

All I need to see is an EXAMPLE - copy it and run it ! Give me a small demo program that uses the functionality I'm looking for and which works, and the rest is history, I'm off and running.
In the TimeChime program all I needed was a small 5 line program that showed me how to create and use a thread, - spare me the theory, just show me. I'll figure out the theory much easier once I SEE the example.
Then I needed a way to call an external file and get the operating system to run it. I didn't have a clue where to look. So the first thing was finding the technical jargon words, then finding examples at actually worked. Voila, done ! Sounds easy but took days and quite a bit of asking around.

And that takes me to the other often neglected key about programming. Programming is a SOCIAL ACTIVITY ! Yes we all know about the image of programmers as antisocial and awkward and all that. Apart from the fact that the image is wrong, programmers are actually a very gregarious bunch.
That's because programming is simply not possible to do in isolation.
How will you get your hands on all those examples ? Unless you are one of the rare geniuses, who CAN actually make sense of data sheets and Microsoft function descriptions, you will have ask other people for help. It's great if you have other programmers who are present in the flesh, that can be a real bonus. For most of us it's a matter of becoming part of those online forums. While I remember, there is an etiquette about using those forums, please remind me to rave about that another time.


Lesson 2: Pessimism can be useful: Of course I should have mentioned earlier on that the very first step in any programming task I do is, to look for what scares the living daylights out of me. I look for the things that really I have no clue about and that make or break the project.
When I wrote the windows AutoTester I knew I had to find a way to call the operating system from my program, make it run another, second program, get the output of that second program and bring it back to MY program. In other words I wanted my program to behave like a computer user who clicks on a program or a file and runs it, gets the output and then takes some actions depending on the output. That's all. Is that asking too much ?



Sure, for the AutoTester there is also a whole lot of database management stuff, and admin work which the program has to do, but that is all just sheer hack work. If can't solve the core issue of running another second program from MY program and reading the output, I might as well not bother starting. No point taking off in a plane if you don't have enough fuel to get to the next landing strip.
So that's why I focus on the really scary bits. After they are taken care of the rest is "carry water and chop wood" as they say. Not to be underestimated, but its the second thing, the first thing is the core task, get that done and then the rest is a matter of hard work only.

How do I find the scary bits ? I go through the steps, break it down until I'm confident I can handle all the parts.
Do I ever miss anything ? Yes, but not too often. There is always an expected problem ready to pounce, after all remember Murphy's laws ! :-) But this method has stood me in good stead.
In June 1997 I was on my way to Tokyo. I knew they wanted me to write a windows GUI program. I had no idea how to do that. Borland Builder 1.0 for drag and drop GUI design had just come out, and I bought a copy at Panthip Plaza in Bangkok on the way. That saved me.


Lesson 3: Debugging - how to make it less painful: I have been through the laborious and frustrating -want-to-throw-computer-through-window phase too many times. So I like to make life simpler for myself. I set up a simple way to turn debugging on and off by using

#define DEBUG 1

By range checking everything and I mean every argument passed to a function both BEFORE its passed to the function and once its IN the function itself.

Any errors are immediately flagged, and printed with filename and line number using
___FILE___ and __LINE___

I even go to the trouble of creating special error logging and display functions that are called the instant anything goes the tiniest bit off the track I want it to follow.
Why ?
Because I'm a control freak ?
No, because I want an easier life.


If I find out the second a parameter goes out of range it's much easier to pin down where it went wrong and why. What usually happens is that something goes wrong, which is not picked up, but affects something else, that is not picked up. By the time the chain of bugs grows and is noticed it's a long way from the place where the trouble started. You don't really want to have IO problems and messy databases before you realize something is wrong.

This is the way to have such an easier life as a programmer.
How much of my code is error checking code ? definitely more than 50%, probably 60 to 75%.

I didn't start like this. I had not read anything about debugging and error logging. These things came out of the school of hard knocks, great frustration and painful silly errors.



Lesson 4: The slow way is faster –o- Less is more - and other clever Zen Koans.
The principle is simple:
Compile and run EVERY time you change anything ! that means anything, even stuff you are SURE won't make any difference. Trust me everything makes a difference. (Everything is part of the whole and even one grain of sand changes the mountain forever - Thank you Grasshopper... for more of that Zen stuff... )

This brings me to the three golden rules of programming:
1) compile and run and test EVERY STEP
2) compile and run and test EVERY STEP
3) compile and run and test EVERY STEP
Yes, you can be lucky and write 10 lines of code and they work ! Just as you can be lucky and win the lottery.
More often than not when I write 10 lines of code I spend an hour or more debugging it. If I had written and compiled it after every line I would have easily picked up the error in line 3 and be done in 20 minutes.



Lesson 5: Ignore all advice and find out for yourself. Whenever I came across articles of advice like this one, I used to ignore them. These things were almost as bad as reading instructions manuals. Everyone knows that reading a manual is like cheating in way and lets face it: we’re all clever and smart enough to write code and figure out things for ourselves.

So yes, ignore all the above, find out for yourself. If you do happen to read up to this point, some of it might have sunk in and made the learning a bit faster. I hope so.

And one last thing: Why did I choose to write the TimeChime program ? Because I really like those Grandfather clocks that chime every quarter hour. I saw a Yahoo widget that did just that but I didn't want to run the Widget engine, and wanted to play different sounds and when they played them.



----------- DOWNLOADS -----------





TimeChime program
A simple program that plays a chord of chimes every few minutes.
Developed: Melbourne 2007, 2008 - using DevC++ and nothing else.
Full version: Download exe here
Full version: Download eee here
Source code included.

Other software milestones/pebbles:
(- note: this is now old software and will look old and dated, but was once state of the art. )

AMI program - Measures the transient conductivity of acupuncture points in the tips of the fingers. From this it makes an inference about the health of the meridian and the organ to which those points belong. -
Developed: Tokyo 1997 at the Tamamitsu Shrine Inokashiara Koen, Tokyo - using Borland C++ Builder and graphics libraries.
Demo version only: download exe here
Demo version only: download eee here

Adaptive Patient Controlled Analgesia Program.
Imagine the worst pain possible, then imagine the most powerful pain killer. Patient Controlled With Analgesia (PCA) patients press a button and an infusion pump injects pain killer directly into their bloodstream. The principle is demonstrated in this demo version.

Developed: Version1: Melbourne 1991 - 1995 in C++, University of Melbourne and The Royal Melbourne Hospital. Not for public release.
Version2: Melbourne 1998 - 1999 Borland C++ Builder and graphics libraries. Mondo Medical PTY, (venture capital company).
Demo version only: download exe here
Demo version only: download eee here
Adaptive PCA was Heiko's PhD research project: For thesis click here.

http://eprints.infodiv.unimelb.edu.au/archive/00003162/


What’s an ‘eee’ file ?
The download files are givens as zip packaged containing .exe files or .eee files.
At the "paranoid" setting some security software prevents the download of .exe files. If this is a problem simply download the zip package with the file that has the .eee extension, save it to disk, and manually change the extension to .exe then run it in the usual way by double clicking on it. Example : download the Zip package containing Ami.eee then rename it to Ami.exe and run it like a normal .exe file.

Any DLL or other files should be kept in the same folder as the .exe files for the programs to run properly.

Disclaimer: All software was clean, secure and working when created, i.e. no spyware or malware has been intentionally introduced. However in these days of dearth of commonsense and complicated crazy legal scare mongering, no warranties of any kind are given or implied. Use as is, at your own risk.

And spelling out some more commonsense: All software is for demonstration of my programming skills only and is not intended to give any kind of medical advice or recommendations - again one would hope that this should be commonsense for the average man-in-the-street.

© 2003-2005,2006 heiko rudolph

Sometimes the threads on the loom suggest the picture to come. Then we know that our children-to-be Hope for us in the bardo. For them we weave until out arms grow tired.

from: The years of Rice and Salt - by Kim Stanley Robinson

How to ask ‘intelligent’ questions in forums and discussion boards. ... & get the information you want..

• People don’t like being take advantage of.
• People like helping.
• You get back what you give out.

Those three lines sum up all I will talk about here.


Whenever a student asks me a question a little filter system runs in my mind: It goes something like this:
‘Have they put in a fair effort ?’
Are they just using me to because they are too lazy to lift the spoon to their mouth ?’
If I get the feeling that some effort at finding an answer and some thought has gone into the problem, I will answer it.

If I get the feeling that the question has been dashed off in a great hurry without much thought or effort I’ll simply ignore it, or I might write an article like this instead.


If you are ASKING a question:

You are asking for a favour, the forum does not HAVE to give an answer, they don’t OWE you anything.

The people who answer do so out of goodwill, from the goodness of their hearts.

They are not stupid and they don’t like being taken advantage of.



Therefore:

Make it easy for them to answer you.

Thank them.



If you are ANSWERING a question:

Reward genuine effort, ignore everything else.

Remember the questions you once asked.

If you want tell someone where to go: don’t !



A famous hacker guide on how to ask questions
http://www.catb.org/~esr/faqs/smart-questions.html



On a discussion forum:


When posting a question:

Use a descriptive subject line for your posts :-)



Don’t do this:

Q: “help, my code won’t run”

A: do you want me to play twenty questions and tease out the problem for you ? If you can’t be bothered thinking about the key issue you want help with I can’t be bothered reading past your subject line.



The twenty questions game:

“What is wrong with your code dear ?”

“Every time I run my code I get an exception and the system crashes”.

“What did you do just before the problem happened?”

“I don’t remember”.

“Can you go back to a previous version?”

“I don’t remember what my previous version is”

“How about chopping out the most recent code and seeing if the problem still continues?”

Etc… Unless the person answering is being paid a huge rate by the minute the conversation will probably never get this far in real life.



Most self-respecting programmers won’t bother to extract the key question from you, you have to give them the core problem in a clear and precise a way as you can. Convince them that you are worthy of an answer. It’s not really that hard.



Do this:

Q: “ modulus operation for hexadecimal base conversion gives random results ”

A: this shows some thought, and tells me what we are dealing with. An experienced programmer immediately clicks through her list of common mistakes using modulus. It only takes a quick read to identify the issue and voilá the problem is solved !



Q: “After encapsulating the complex number addition in a function the program crashes every time a negative real number is passed. I’ve tried XYZ”

A: This question shows some thought, effort and is clearly expressed. It sounds like someone I want to help.



Posting questions summary:

tell us what you have done so far, what you tried, and what you really need help with.

- what errors did you get ? what was the error message ?

- what exactly did you enter ?

- supply relevant information - your code, just the RELEVANT bits... . if you don’t want to wade through pages of someone else’s code don’t send them pages of your code.



Golden rule before you post a question:

Put yourself in the shoes of the person reading your question.

Read your post and imagine how you would feel if someone asked you that question.



BLANK general questions that sound like the questioner wants others to do the work

for him and that does not get much response.



SOME kind of attempt at an answer is a good idea and means that others are much more likely to want to help you.





How to get useful help:



Read this: http://www.catb.org/~esr/faqs/smart-questions.html

Really I mean it, read this, not just for this course, but it is a wonderful hint sheet on how to get what you want in life GENERALLY, not just on a discussion forum !



Do the following:

- say what you tried.

- what did you get ? what is the EXACT error message ?

- give code, but ONLY relevant code, give enough to give me an idea, but do NOT dump the whole file into an email and hope I will have time and inclination to sort it out for you. I won’t. I’ll help if I get the feeling you have made an effort to present your problem clearly and you have tried the logical next steps.



Most people are happy to help if they see that the person is genuine and has tried the help himself.



A humourous look at how to ask good questions here: stackoverflow.com/faq

Favourite programming cartoons stackoverflow.com/questions/84556/whats-your-favorite-programmer-cartoon

What not to do:



A real example:

Q: " i get error "invalid variable " and don't know what it means ? how do I compile to get it working ?can u help? "



Well yes, I "can" help.

Next question?



The kindest answer would be simply to send them a link to this page. http://hycoteaching.blogspot.com/2009/01/how-to-ask-intelligent-questions-in.html

If you get a link like that, then please read and take notice J .



For some reason bad spelling, sloppy grammar often go together with lack of effort and careless thinking. Whenever I see bad spelling, sloppy formatting and fuzzy grammar I lower the effort I put into my answer by 70%+. It may not be fair and it may not be a logical response, but it is how much of the world reacts too.



Another real example: (names changed)

On Wednesday, 12 October 2008 at 04:01 pm, "Mr Speedie" wrote:

hii, i'm having some problem on lab 4.

First, for the decoded part, are we just separate into three in a group from the begin even the strlen of parameter is not multiple of 3?

Second, how can we separate the parameter into 3 in one group?



Hi Mr Speedie,



- ask at the discussion board,



- have you asked a tutor in your labs ? What did they say ?



- come to Wed 12;30 help session.



- talk with friends...



- when you ask questions like this: it would be good to show some effort: what have you tried yourself ? your question is TOO general.

Even for discussion board: show what you have tried, show what you think, then ask for confirmation.

It sounds like you are asking people to do the work FOR you. That never gets much of a response....



- when you have tried the above and have some code of your own to show, let me know :-)



good luck



Mr Grumpy.





How much time would you spend answering a question that looks like it was dashed off between a browser refresh cycle ?





The same principles that apply to getting help with programming and coding apply to the rest of life:



Example email from a student to a lecturer.



...my report mark is too low could you please reconsider ?

thanks.

J. Student



This is what the lecturer would have to do to answer such an email:



1) Lecturer has to forward email to tutors and ask who the tutor was: “is this student in your lab class ?”



The student simply did not put herself into the shoes of the person who was receiving this email) -> result: student collects 3 virtual negative grumpyness points



2) the lecturer usually has many different courses, it would save time and effort to clearly say what course the student is in. Having to hunt around for student numbers and searching spreadsheets means the student collects another 3 virtual negative grumpyness points



3) no history of what the problem is: it would be nice to know if there was anything unusual about this request, (there often is and it takes a lot of emailing back and forth to dig it out)

“Why do you think you deserve more marks ?” etc…etc… etc.. 3 more emails.

-> result: student gets anther 3 virtual negative grumpyness points (in the mental counting system)



4) Tell the lecturer if you have dropped a copy in the digital drop box, perhaps attach a copy to make it easier to see. Each time a person has to hunt around a database or a Hard Drive the chances of you getting what you want drop.



Ok you get the idea by now, I'm sure.



The basic principle is: if you want something from someone and you rely on their good will then make it AS EASY AS POSSIBLE for the person to give it to you.

How ?

Show that you value the person's time by



+ Supplying all relevant information: student number, course, tutor name, exact clear description of problem

Don’t make them play detective.... they may not bother to answer you.



+ Show respect, it won’t hurt and might even help J



+ Put yourself into the receiver's shoes and imagine what they might want to know, do your really think they will increase your mark just because you ask ? OR do you think they might like to have a GOOD reasons ??? ........... )



These are basic simple tricks and tips you can use in any situation in life where you deal with a bureaucratic rule based systems (University, Government, Companies... cubicle life a la Dilbert www.dilbert.com ).



Surprise surprise: Lecturers actually DO want to be fair to you, and do the best for you.



From now on, if someone emails me with some cryptic kind of message I'll reply with a link to this page and let you figure out what might be missing :-)



Heiko



Dilbert:

http://www.dilbert.com/comics/dilbert/archive/dilbert-20061105.html


© 2003-2009 heiko rudolph

Sometimes the threads on the loom suggest the picture to come. Then we know that our children-to-be Hope for us in the bardo. For them we weave until out arms grow tired.

from: The years of Rice and Salt - by Kim Stanley Robinson

Does Groupwork destroy Individual skills ?

- does working in groups degrade individual skills ?

You all know the familiar scenario: Many groups of approximately 5 students each. In each group two or three students drive the project, do the bulk of the work (80%) and the others are effectively passengers and take care of the remaining 20% of the work.



As teamwork and group building goes this works fine, it teaches skills that are required in all walks of life and it can be argued that this is actually what tends to happen in the workplace anyway.

The only casualties are the skills of the ‘passengers’.

This has been one of the main arguments against group work assessment in the past.



The other approach has been to eliminate groupwork (usually because of the ‘passenger phenomenon’) and to assess students only on their individual skills. This ensures that the each student actually DOES acquire a certain level of skills.

The casualty in this approach are teamwork skills. Teamwork skills are an essential component in any job and should be part of a University education. Most work is done in teams because they are more productive. Software programming and most professional engineering jobs benefit from a team approach. It is comparatively rare for professional individuals to work alone.



Open Combining the benefits of groupwork and individual work:

There is a way of combining groupwork and still ensuring students acquire individual skills in what are called ‘public assignments’.



A public assignment is an assignment which is well known before the test and allows students to work out solutions in teams, with friends.

Assessment is at an individual level, where each student is tested and must be able to complete the assignment tasks on her own.



Here are some practical steps for this approach to work best:



Ø The public assignment problem must not be so small it can be easily memorized with little understanding, nor should it be too difficult for a one or two hour test.

Ø Testing should be carried out in standard examination conditions i.e. students should not be able to copy others work nor bring outside work to the test.

Ø Skills assessment is carried out outside laboratory classes in a clearly defined way. The assessment criteria should be publicly known and students are advised to prepare for it.

Ø Assessment is best carried out by one person or in a standard way. This may be through an automated marking process, or by the lecturer or tutor.



In using the public assignments approach there have been some unexpected benefits –



Ø Non-performing students are identified early in the semester and can be contacted and requested to come in for extra help.

Ø Students see little advantage in attempting to get a delay in marking through simulated ‘illness’. In actual practice the incidence of medical certificates for illness at test times dropped dramatically when compared to the standard secret test questions approach.

Ø Students with medical certificates and absent due to illness do not require a new assignment.

Ø In most laboratories tutors spend most of their time marking and so have little or no time to tutor and help students. In our labs the tutors were totally relieved of any marking during laboratory times and so were able to help students for the entire time.

Ø We have found that many tutors find it difficult to move between the roles of tutor and assessor. Most tutors in our experience give a pass for little or minimal work thus masking student incompetence to both staff and the student.

Ø Marking carried out outside the laboratory along clearly defined guidelines has little such bias and competency issues are discovered early in the semester when there is still the possibility of intervention and recovery.

Ø Students often reported problems with different tutors marking to different standards, some were easy markers, others were disproportionately severe. Public assignments are marked to a consistent standard. To achieve this, marking best carried out by one person, or one method outside the laboratory times, and along well defined paths.

Ø It is easy to give students a second or third chance at the problem, with either a marks discount or some variation of the original problem.

Ø We have tested this approach with engineering problems and found that students not only had to focus on programming but also needed to carefully read the specifications of the public assignment. This was exactly the educational outcome we desired and matched what employers tell us they value in graduates.







Groupwork has always been a reality of study at any University, whether students worked in ad hoc friendship groups and then underwent individual assessment of or whether they worked in formal groups. It could even be said that a good support network of friends is a key ingredient of success at University.



By using public assignments, students are encouraged to work in teams and yet each student is assessed on their individual skill level. Passengers are eliminated and the best of groupwork and individual work is obtained.



This approach is clearly communicated to the students. Students are encouraged to work in small teams to share, help each other and learn in groups.


© 2003-2009 heiko rudolph