Tag: software engineering

Entries for tag "software engineering", ordered from most recent. Entry count: 35.

Uwaga! Informacje na tej stronie mają ponad 5 lat. Nadal je udostępniam, ale prawdopodobnie nie odzwierciedlają one mojej aktualnej wiedzy ani przekonań.

Pages: > 1 2 3 4 5 >

# About the Guy Who Made Love

Sat
22
Aug 2009

Today I want to talk a bit about what's the dream of almost every passionate game developer. It seems very hard or almost impossible to achieve, but younger amateurs still hope that they will manage to do it someday. Of course I'm talking about making a 3D MMO game.

As it turned out for me today (thanks for the link KriS!), it actually IS possible. I'm talking about the game called Love written entirely by one person - Eskil Steenberg. He have coded all the software from modeling tools through network protocol and renderer until game mechanics. To see it working I recommend watching these videos. The game is powered by his engine called Quel Solaar, which is actually available for download.

I must admit I haven't been impressed so much for a long time. I suppose the amount of time and passion that had to be put into this code is enormous. Graphical style and gameplay, as well as the user interface of his tools are very unusual and surprising. And all of this is made by one guy...

I recommend watching his lecture from this year's Assembly party titled Developing the technology behind "Love". You can see many technical details and if you don't want to watch the entire one hour video, at least watch the beginning (where he talks about his "smarter way of doing things") and the ending (where he expresses his thoughts about the value of good tools).

BTW it's also nice to watch new videos from GC 2009 of the CryEngine 3. "What you see is what you play" and instant asset update (including textures) - that's how good game editor should look like :)

Comments | #software engineering #networking #web #rendering #games #events #engine #demoscene #philosophy #tools Share

# How Do People Write Bad Code

Wed
05
Aug 2009

Recently yarpen posted some thoughts about source code scalability on his blog. His blog entries are always very valuable and this time he touched broader subject which is connected to software antipatterns.

I want to expand this subject further and think a bit about how is such bad code created (we all agree that non-scalable code is bad, right? :) In my personal opinion it's generally caused by the lack of thinking. For example, if a coder have to code something (or, how some people would like to say: to solve a problem), he should first consider what possible solutions are. This may be choice of a technology, programming languages and libraries, some design patterns, algorithms, data structures or even names for some objects. If he doesn't think about it, he just selects the first option that came to his mind without considering alternatives and thus risks that he didn't make the best possible decision.

Next, the coder should design his solution. Designing is all about thinking before doing. If he skips this step, he may meet during his coding a situation when sees he came the wrong way and now he must refactor or even delete big part of his code and then just... rethink it :) I like the saying It's better to think twice before you start coding than to code twice before you start thinking. :)

The same applies to all changes made to an existing code. If somebody have to change something in a program, he'd better review the code carefully to discover and understand its architecture. If he just starts making changes to the code, he risks that he will break some hidden assumptions in some aspects of the code (like variable values, objects lifetime, order of function calls etc.) and thus create bugs.

The reason behind writing poor code may be rush. If a coder wants to code something as quick and simply as possible (or his boss tells him to do it this way), he will do ugly hacks and never refactor anything, even if some refactoring is necessary at this point. Of course this it to bad code and will backfire in the future, when the code will have to be changed and it will turn out to be totally unscalable. So we obviously see that such attitude is just the lack of thinking.

But this problem may also be something deeper. I can see that some coders just always write bad, unscalable code by their nature. I don't want to offend anyone, but I think maybe that's the crucial difference between junior and more experienced programmers. To work as a programmer, everyone needs to "speak fluently" his programming language to freely express his thoughts using it, but experienced programmers are also able to see a bigger picture - some invisible assumptions and more abstract concepts behind the code. They see words like "handle", "manager", "alignment", "serialization", "callback" and hundreds of other terms (anyone thought about creating coder's dictionary with words like these?) and just knows what hides behind them.

Three days after yarpen's entry there appeared a blog entry about code documentation on EntBlog. It describes two main types of documents - API documentation and technical articles. I fully agree with this text. I value documentation very much and I think that good documentation is another piece of this big puzzle.

They say that there are two types of people: these who make backups and these who will make it :) I think it's the same with writing good code and documentation. It's just the matter of thinking forward.

Comments | #software engineering #philosophy Share

# Humor komputerowy

Mon
25
May 2009

Jest dużo stron z humorem i każda ma swój klimat - np. Joe Monster.org, funiaste.net czy Perełki.net.

Z takich typowo komputerowych najlepsze są chyba bash.org.pl (który zbiera cytaty z IRC) i przede wszystkim Roflcompter.pl (dowcipy informatyczne i matematyczne). Dawno się tak nie uśmiałem, jak czytając ten ostatni :) Humor komputerowy zbieramy też na Warsztacie w dziale Humor. Z innych perełek to gorąco polecam Choinki matematyczne. Ponieważ oryginalny link od pewnego czasu nie działa, pozwoliłem sobie zrobić MIRROR. W ogóle to najśmieszniejsze moim zdaniem obrazki (głównie humor komputerowy) zbieram w katalogu regedit.gamedev.pl/pub/Humor.

Żeby ta notka nie była bez ani jednego dowcipu, przytoczę dwa - niestety mające dużo wspólnego z całkiem poważną rzeczywistością.

Gdyby murarze budowali domy tak, jak programiści piszą programy, to jeden dzięcioł zniszczyłby całą cywilizację.

Dlaczego tak jest? Trafnej odpowiedzi udziela inny dowcip w temacie informatyczno-budowlanym:

Jak do kierownika budowy przyjdzie klient i, w momencie kiedy jest już położony dach, powie, że on by chciał jeszcze jedno piętro pod tym dachem, to kierownik popuka się w czoło. W analogicznej sytuacji kierownik zespołu programistycznego zapyta:
- A na kiedy?

Comments | #humor #software engineering #web Share

# Fanatyzm obiektowy i mania wrapowania

Tue
31
Mar 2009

Napisałem mały felieton, esej czy jak to się tam nazywa (polonista ze mnie kiepski :) Zwykle nie lubię narzekać, wolę pozytywnie podchodzić do życia. Nie lubię też wygłaszać swoich poglądów (bo "poglądy są jak d*** - każdy ma swoje, ale po co je pokazywać" ;) Jednak tym razem postanowiłem podzielić się swoimi przemyśleniami na temat programowania obiektowego. Tekst nosi tytuł Fanatyzm obiektowy. Właściwie to ten tekst umieściłem w dziale Download już dawno temu, ale dzisiaj dopisałem do niego nowy rozdział - "Mania wrapowania". Zapraszam do czytania i komentowania.

Comments | #software engineering #philosophy #c++ Share

# Stawianie realnych celów

Tue
19
Feb 2008

Pasjonaci programowania gier często porywają się z motyką na słońce próbując napisać samemu kompletną grę - taką jak sobie wymarzyli, np. taką jak GTA albo WoW. Nawet jeśli mieliby potrzebną wiedzę i doświadczenie, oczywiste jest, że nie sposób tego dokończyć - to by wymagało wielu lat pracy. Szczególnie, jeśli nie ma motywacji w postaci pieniędzy ani szefa straszącego zwolnieniem, a na horyzoncie pojawią się często nowy, jeszcze lepszy pomysł.

Ja nie twierdzę, że to jest złe. W pewnym sensie to jest tak samo dobre, jak każde inne programowanie - robisz to co lubisz i zdobywasz doświadczenie. Jednak porzucanie coraz to nowego niedokończonego projektu może rodzić frustrację.

Dlatego może warto zacząć wyznaczać sobie realne cele. Zacząć od przyznania się przed samym sobą, że nie jesteś w stanie sam jeden napisać gry takiego kalibru, jak GTA czy WoW. Następnie pomyśleć, co mógłbyś napisać, żeby pozostając w kręgu swoich zainteresowań jednocześnie było możliwe dokończenie tego. To mogą być różne rzeczy. Jeśli chcesz zrobić dobry uczynek, napisz bibliotekę, którą inni programiści mogą wykorzystywać w swoim kodzie. Albo demo, które będzie się miło oglądało. Albo efekt wraz z kodem źródłowym i opisem, z którego inni będą się mogli czegoś nauczyć. Albo program narzędziowy, który przyda się innym programistom.

Oczywiście, punkt widzenia zależy od punktu siedzenia (a także od wieku i doświadczenia). Dlatego wcale nie twierdzę, że moje podejście jest jedynie słuszne. Myślę jednak, że ma pewną dużą zaletę - tworzy portfolio dla przyszłego pracodawcy. Pracodawcę interesuje podobno przede wszystkim "co umiesz", a zaraz potem "co możesz pakazać". Myślę, że w tym kontekście małe, ale ukończone i przydatne kawałki oprogramowania mają większą wartość, niż duże, ale tylko rozpoczęte gry.

Comments | #software engineering Share

# Biblioteki - gotowe czy własne?

Mon
23
Jul 2007

Wyczytałem wczoraj przy okazji w jednym z artykułów na GameDev.net, że potencjalnemu pracodawcy bardziej spodoba się, kiedy zobaczy, że programista w swojej amatorskiej produkcji skorzystał z gotowych bibliotek (co jakoby dowodzi jego umiejętności używania cudzego kodu i skupiania się na swoim celu), niż gdyby pisał wszystko samemu (co pokazuje jego umiejętności programistyczne). Ciekawa teoria. Brzmi całkiem logicznie.

Comments | #philosophy #libraries #software engineering Share

# Filozofia #1

Sat
21
Jul 2007

Kiedy człowiek ma dużo wolnego czasu, to za dużo myśli i przychodzą mu do głowy różne dziwne rzeczy. Dlatego to jest pierwsza cyklu notek filozoficznych. Wszystkich zdegustowanych czytelników mojego bloga przepraszam i obiecuję, że kiedyś mi to przejdzie :)

Myślałem sobie mianowicie o tym, jak wiele czasu potrzeba, by stworzyć cokolwiek - czy to będzie napisanie książki, zrobienie swetra na drutach czy napisanie jakiegokolwiek, małego nawet programu albo gry. Wielokrotnie więcej, niż wydawałoby się komuś niewtajemniczonemu albo początkującemu programiście. A czas mija nieubłaganie. Dlatego trzeba jak najstaranniej dobierać sobie zadania do wykonania - zarówno duże projekty, jak i te drobne sposoby na ich zrealizowanie.

Inna związana z tym sprawa to paradoks, że niejednokrotnie boimy się i nie możemy się zabrać za zrobienie czegoś, co w końcu zajmuje nam nie więcej niż 15 minut (np. zadana w szkole praca domowa), a innym razem angażujemy się w coś małego, co niespodziewanie zabiera wiele dni. Dlaczego tak jest? Moim zdaniem dlatego, że tym, czego podświadomie się boimy jest wysiłek, a to, co liczy się naprawdę to czas - dwie różne rzeczy.

Jeszcze inna kwestia to motywacja, która może wielokrotnie przyspieszyć robienie czegokolwiek. To jednak nie jest lekarstwo na wszystko - bo dlaczego firmy informatyczne nie zatrudnią po kilku młodych genialnych amatorów z motywacją zamiast armii tak niewydajnych w porównaniu z nimi programistów? O tym pisze Frederick Brooks w książce "Mityczny osobomiesiąc".

Comments | #philosophy #software engineering Share

# Projektowanie API

Thu
28
Jun 2007

Projektowanie interfejsu biblioteki jest równie ważne, jak projektowanie interfejsu użytkownika programu. O tym drugim napisano całkiem sporo. Sam mam jedną książkę właśnie na ten temat. Co z tym pierwszym? Czy ktoś widział jakikolwiek tekst poświęcony projektowaniu dobrego API? Ja znam tylko jeden mały artykuł - Designing Qt-Style C++ APIs napisany "przy okazji" przez autorów biblioteki Qt.

Comments | #software engineering Share

Pages: > 1 2 3 4 5 >

[Download] [Dropbox] [pub] [Mirror] [Privacy policy]
Copyright © 2004-2021