2010-09-09
2010-08-23
Stephen Fry & Hugh Laurie
Régi cucc, ami csak nekem új. Dr House egy másik élete.
Old stuff which is new for me. Another life of Doctor House.
Old stuff which is new for me. Another life of Doctor House.
2010-08-16
Villamosos üldözés / Tram pushuit
Have a good evening!
In current days, while the criminal acts are spreading, the daredevils of the gangland invent newer and newer ways to deliver their deeds.
The following police recording proofs that criminals are not picky about the vehicles they use during robbery.
In current days, while the criminal acts are spreading, the daredevils of the gangland invent newer and newer ways to deliver their deeds.
The following police recording proofs that criminals are not picky about the vehicles they use during robbery.
2010-08-15
2010-08-12
Editing JPEG DPI without resampling
The title is the naive search term for a problem. The good search term - or Google power phrase - is
P.S.: I decided to publicate the fruit of every hard and exhausting search on this blog. Maybe it is not good for the regular visitor, but I'm sure it helps the Universe in general. :-)
--- Hungarian version
JPEG DPI szerkesztés: Ez a jó neked:
Exif editor. The best of the results which simply solves the problem is the
Exif Piloton an
Exif editorspage. Enjoy!
P.S.: I decided to publicate the fruit of every hard and exhausting search on this blog. Maybe it is not good for the regular visitor, but I'm sure it helps the Universe in general. :-)
--- Hungarian version
JPEG DPI szerkesztés: Ez a jó neked:
Exif Pilotaz
Exif editorsoldalról.
2010-08-11
Welcome to Ruby
myString = "Welcome to JavaScript!" => "Welcome to JavaScript!" myString[8..20]= "Ruby" => "Ruby" puts myString => "Welcome Ruby!"
2010-07-22
LOLCODE
~ is an esoteric programming language inspired by the language expressed in examples of the lolcatInternet meme. The language was created in 2007 by Adam Lindsay, researcher at the Computing Department of Lancaster University.
The language is not clearly defined in terms of operator priorities and correct syntax, but several functioning interpreters and compilers already exist. The language has been proven Turing-complete.
-- Wikipedia
Examples
- Hello World!
HAI CAN HAS STDIO? VISIBLE "HAI WORLD!" KTHXBYE
- Print numbers from 1 to ROOF.
HAI CAN HAS STDIO? I HAS A ROOF, I HAS A VAR ITZ 0 GIMMEH ROOF BTW U R IN CONTROL IM IN YR LOOP UP VAR!!1 IZ VAR BIGGER THAN ROOF? KTHXBYE VISIBLE SMOOSH VAR AN ":)" MKAY IM OUTTA YR LOOP KTHXBYE
→ lolcode.com
2010-07-20
2010-07-18
Publishing detailed error messages
As an opposition to "Hiding error details". On the input of [Posa1996]1 page 43 (Architectural patterns (2) / Layers (2.2) / Implementation / 10):
I have to strongly disagree with the author on that point. It is far more worse if the highest layer of all gets an error like "Error." without any details. The error message should be as detailed as possible. Do not be confused! That does not mean that higher layers should not handle these errors in a grouped manner. For example if a file transfer fails on any reason the program logic should abort the transaction, whatever the reason of the failure is, so the so called voluminous error-handling code can be avoided. Not handling but publishing the details of the error can help the user understand and solve the problem. Making distinction between "Directory not found.", "Drive not ready.", and "Permission denied." is very useful at the level of the user (or customer care, product support line, developer, whoever).
Testing, debugging and user support can be a horror without detailed error messages. It can be counted in serious amount of money. If the user does understand the error message then it is an instant win for the user himself/herself and for the customer care both. If he/she doesn't understand then he/she has something to tell at official and unofficial support forums which will bring the solution closer. It is a win-win decision to keep the error messages detailed.
And again, it does not contradict the "keep the volume of error-handling code low" principle. Handling ≠ publishing.
→ 1: [Posa1996] Frank Buschmann et al.: Pattern-oriented software architecture, Volume 1: A system of patterns; © 1996 John Wiley and sons
Design an error handling strategy. Error handling can be rather expensive for layered architectures with respect to processing time and, notably, programming effort. An error can either be handled in the layer where it occurred or be passed to the next higher layer. In the latter case, the lower layer must transform the error into an error description meaningful to the higher layer. As a rule of thumb, try to handle errors at the lowest layer possible. This prevents higher layers from being swamped with many different errors and voluminous error-handling code. As a minimum, try to condense similar error types into more general error types, and only propagate these more general errors. If you do not do this, higher layers can be confronted with error messages that apply to lower-level abstractions that the higher layer does not understand. And who hasn't seen totally cryptic error messages being popped up to the highest layer of all - the user?
I have to strongly disagree with the author on that point. It is far more worse if the highest layer of all gets an error like "Error." without any details. The error message should be as detailed as possible. Do not be confused! That does not mean that higher layers should not handle these errors in a grouped manner. For example if a file transfer fails on any reason the program logic should abort the transaction, whatever the reason of the failure is, so the so called voluminous error-handling code can be avoided. Not handling but publishing the details of the error can help the user understand and solve the problem. Making distinction between "Directory not found.", "Drive not ready.", and "Permission denied." is very useful at the level of the user (or customer care, product support line, developer, whoever).
Testing, debugging and user support can be a horror without detailed error messages. It can be counted in serious amount of money. If the user does understand the error message then it is an instant win for the user himself/herself and for the customer care both. If he/she doesn't understand then he/she has something to tell at official and unofficial support forums which will bring the solution closer. It is a win-win decision to keep the error messages detailed.
And again, it does not contradict the "keep the volume of error-handling code low" principle. Handling ≠ publishing.
→ 1: [Posa1996] Frank Buschmann et al.: Pattern-oriented software architecture, Volume 1: A system of patterns; © 1996 John Wiley and sons
2010-07-16
Processing.org
Processing is an open source programming language and environment for people who want to create images, animations, and interactions. Initially developed to serve as a software sketchbook and to teach fundamentals of computer programming within a visual context, Processing also has evolved into a tool for generating finished professional work. Today, tens of thousands of students, artists, designers, researchers, and hobbyists who use Processing for learning, prototyping, and production.
→ processing.org
The apropo for posting this is that I regenerated my toy applets that I wrote in this environment.
→ My graphic applets, with source code. Enjoy!
2010-07-14
Silver needle in the Skype
BlackHat Europe, March 2nd and 3rd, 2006
→ skype_BHEU06.pdf
Repost of a synsecblog entry.
If you can repeat their results you rock!!!
Codility (x)
Automated tests of programming skills.
Codility administers short programming tests and checks whether solutions are rock solid.
Our customers filter out up to 90% of candidates. Less wasted time. Better hires.
→ http://codility.com/
2010-07-09
2010-07-07
2010-06-28
2010-06-25
French and Italian soccer / Francia és olasz foci
A francia és az olasz csapat tagjai tegnap közösen meglátogattak egy fokvárosi árvaházat.
Szívszorító volt látni a szomorú kis arcukat és a reménytelenséget– nyilatkozta a 6 éves Dzsamal.
--- English version
The members of the French and Italian soccer teams joined together and visited a shelter for orphaned children in Cape Town.
It was heart-smothering seeing their little sad faces and the hopelessness– explained Jamal the 6 years old boy.
2010-06-23
Subscribe to:
Posts (Atom)