Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:I would be too (Score 1) 285 285

Also allow me to remark, that working overtime also is not necessarily a sign of professionalism, maybe even a sign of absence. I know how many hours I can work, before I am mentally exhausted and will introduce more errors / damage then benefit. As a professional thus I will insist staying below this threshold for the better of my employer and myself.

Comment Re:I would be too (Score 1) 285 285

A contract is two-sided. If one sides wishes to divert from the agreed-on terms I am sure the other side will be open for honest renegotiation so everything stays fair.

Also working overtime is a sign of bad planning, which might be the workers or his managers fault. Either the worker agreed on deadlines he should not have accepted or the manager tried to put too much work on the worker. Yet it should have been noticed early enough and the time / work could have been renegotiated. This of course requires professionalism of both sides: Don't try to hide your errors and give a early enough notice, and listening to employers and accepting that errors _are_ happing, if you are told or not.

Comment Re:One thing to keep in mind... (Score 1) 244 244

I disagree: Give me a really concise documentation and if there is still time then go wild on a conversational info page / demo / tutorial / best practices

  First one should be easier and faster to do and you can always reference to it for details in the more wordy thing. Examples and explanations are important especially if one just starts using the software / API, but cumbersome if I only want to know the expected boundaries of a parameter or so.

So both are important, but for different things. Probably one should not skip any of these. ;)

Comment Re:Peanuts (Score 1) 411 411

The thing you linked more or less said design pattern are bad because... he doesn't like it. He says there is no scientific proof they are good and thus they must be bad (without giving any proof) and because people used them wrong and introduced unnecessary complexity. The argumentation of the GoF is as sound or unsound as his. I can always construct an argument against something if I point out how it is used incorrectly. By this argumentation Assembler, C, C++ and actually every programming language is bad, because I can write really messy code.

I wrote that design patterns are usefull to _me_, yes. I can't generalize my experience, of course. Yet I learned design patterns only quite some years after I started programming. And I really prefer it this way over everyone reinventing the wheel. The code bases I worked on were many years old and more than a million lines of code or so. It just would not have worked without design patterns and code formating rules.

The problem is, that there are almost no useful experiments in software engineering. Each one I saw until now was set up way too small, too short or used students instead of professionals or any combination of this. Really good experiments are just wayyy too expensive, as you would have to watch programming efforts with and without, on the same project, over years, with professionals. Nobody will finance that, unfortunately. And case studies are just case studies and can't be generalized. Thus it is hard to scientifical sound say what is bad or good. It would be great if we could, of course.

Comment Re:Peanuts (Score 1) 411 411

Forgot to note, that patterns also improve communication, as you can just say, you used the observer pattern and everybody (hopefully) knows what it means. Moreover by just harmonizing the code, so that the same problem is always solved the same way, you don't have to dig deep into the implementation to see what is going on. You see ItemsPurchasedObserver and you have a rough idea what's going on. On top you are not forced to reinvent the wheel for the millionth time.

Comment Re:Peanuts (Score 1) 411 411

Well, I don't want to miss at least a couple design patterns: Iterator, Observer, Adapter, Decorator, Dependency Injection, Object Pools (Threads and Connections in my case).
I also sometimes use Singleton, Builder, Proxy, Command, Circuit Braker.

Iterator: I want a simple Interface I know, to iterate over data structures if iterating is reasonable. Not 10 different interfaces for 10 data structures.

Observer: Often I want information to propagate. Yet the business logic should not depend on the UI, so I can easiely provide different UIs. And especally I don't want circular dependencies.

Adapter/Wrapper: Every so often I have to work with slightly off interfaces. Putting an Wrapper around it solves this.

Decorator: You don't have to maintain for example scroll functionality for every dsplay and input type (e.g. Text, Picture) but just do it once.

Dependency Injection: My code is so much easier testable since I use DI. Only downside, I have to admit is, that you potentially have your dependencies defined elsewhere. But then again this allows easier changes of those (for example in case of software product lines).

Object Pools: Thread and connection pooling can drastically improves performance. Noone nowaday creates 1000 new connections per second from one server to one DB.

Yet of course I don't sit there all day and try to use as many design patterns as possible. For a 100 line program I would never use DI, I use a wrapper only, if I really need to. And so on...

Comment Re:"Against a wall" (Score 1) 149 149

There are already things hindering the customers to place their PC directly with their back to the walls. One is called cables, the other one is called convenience. Who wants to crawl under their desk to turn the PC on or to attach / detach an USB flash drive? Thus a PC is more often then not aligned with the front of the desk, with more than enough space towards the wall.

So I call BS on the "regular PCs heat up because of walls and thus we introduced this case design".

Comment Re:Computers Yes. But theres no point (Score 1) 151 151

Even though risking to feed a troll:

Please elaborate why Java is a "slower language before we even start",
why you think java is single threaded (in Java multi-threading is really comfortable, and no libraries needed),
why you say there is no optimization (the JIT compiler DOES optimize the code),
where your "good logic" is, when there are numerous buffer overflows and similar problems regularly found in important C / C++ code,
and why you are thinking you would be forced to use any library? (of course you can reinvent the wheel for the thousands time with the same errors)

Have you ever seen real benchmarks between Java Code and C / C++ nowadays? It doesn't seem so.

And what are you referring to with '"easy" amature programming' and "fast food alpha"?

A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt

Working...