owenSoft.net - Articles

What is a framework? (programming) (Articles)

2012-02-05 18:59:03

The seems to be a growing trend to “re-define” certain things in programming and computer science to fit whatever newfangled meme that comes up. This article seeks to solidify what I mean when I use the work “framework” in a programming and software design context.

Wikipedia provides a clear definition (as usual);

In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API). - Wikipedia

Almost everything involving programming nowadays involves some kind of framework or better yet an “application framework” - it is an unavoidable fact of today’s high level programming needs and the added benefit of the control provided by having a fixed set of rules or a sandbox.

Operating Systems vs Application Frameworks

The Android operating system for example provides a application framework which must be used in order to interact with the hardware and other features of the operating system. This separation allows the makers of the operating system to have better control over the programs that are written on the platform and hense provides a measure of stability to the platform. It is easy to identify the framework by looking at the software stack and its design. The Windows phone 7 application stack is similar but is even further abstracted from the hardware. Abstraction has its drawbacks which I have already discussed.

So basically anything that has a API (that you are forced to use) is a framework, it is an unavoidable evil. The further away from the kernel you are programming the deeper the rabbit hole goes. So framework even require you to use a whole new custom language in order to interface with the API. I can even go as far to say that every program you write is a framework for the user who uses it - its what programmers do - we build layers.

Frameworks are often synonymous with certain keywords; for example Eclipse, Java and Refactoring. Once any of these things are mentioned there is is a 99% chance they they are mentioned in relation to a framework because these technologies eat their own dog food. Having a consistent framework allows tools like Eclipse to do their auto-magic refactoring without many side effects - its a cause and effect situation.

Conclusion

So basically a framework is a application layer - it is not a library, design pattern or paradigm (tough it could be if its restrictive enough). It is a specific abstraction layer. Some frameworks are deeper than others. Some frameworks API are only accessible by privileged root applications provided by the makers of the API while others are “secret”. As the generations progress there will be a increased push towards managed code to solve many problems such as viruses and memory leaks. Some frameworks for example in video games, real-time systems and graphics often require a minimal abstraction and will however continue to operate using a low level framework or even assembly.

by owen () Post your comments on this article

SmartPhone Race Jamaica - Why so many Blackberries? (Articles)

2012-01-23 07:57:26

It has been a few weeks since my last article on Blackberrys - Why they are still cool but it seems that the circle jerk in the fandom is increasing to the point of blind optimism. So I have come back to provide some objectivity.

In this article, I will delve further in to the various social,cultural and economic reasons why (in my humble opinion) the smart phone race in Jamaica will be a long and boring battle. Full disclosure; I have recently bought a BB after years watching and analysing the cellphone market both locally and abroad. I should also say that the Dominican Republic has the best cellphone network in the region. Now, back to the article, I will run across stereotypes, cliches and general opinions based on my personal observations and educated guesses based on...well speculation.

Jamaicans have limited reasources

Jamaicans will only spend their money on things that they cannot get for free, cheap or things that they think are valuable. The credit culture in the end it is all about practicality and a lower cost of ownership - it is not about being “cutting edge” or “trendy”. Why would they spend a small fortune on a smart phone just so that they can download free apps? It is almost like buying a big plasma tv for the benefit of watching burnt DVDs.

Jamaicans Hate Contracts

The majority of the iphones and Android phones require post paid plans, long contracts, lots of cash up front or both. The Jamaican cellphone users are on Pre-Paid plans and withdraw their money in a $1000 dollars at a time from the ATM. It is not because there is not a better, faster or more efficient way - they are just fear varies forms of ENTRAPMENT. Two bills, a bank statement and down payment? Yeah sounds pretty affordable compared to AT&T. Phones get dropped, stolen, sold to pay for car insurance, and left in taxis, it happens everyday in Jamaica.

Slow Phone Networks

Not only are the local networks slow, but in some places you cannot even get dial-up speeds because the coverage is just not up to par - unless you happen tospend all your time in New Kingston or a major town. I hope to see the day when we can do some of the stuff we see in those phone ads on cable. But that day is not today or tomorrow, maybe in 3 years (sans apocalyse). Many people cannot afford (and probably do not know how to) to connect to WIFI to download their Apps because connecting to WIFI would mean that you are either paying for home internet+your cellphone bill or you are squatting on free WIFI for several hours of the day.

Jamaicans do not care about Apps

There are several reasons why phone “apps” are not important; Firstly apps cost money ; free apps are usually bait for paid versions and Apps need to be purchased with credit cards from phone specific app stores. Thirdly, apps cannot be shared from phone to phone - which is not a problem for some but the layman may find it a bit strange. Finally, Apps provide services which compliment similar services provided on a computer, so until there is a proliferation of computer science education, most Jamaicans will have no reason to go searching around an App Market for a potentially useful app - unless its a app that prints money or a game. There are so many cheaper forms of entertainment in Jamaica which brings the argument back to cost and value. An app will have to be quite impressive in order to draw locals away from the local dancehall and stage show. It is nice and sunny in the tropics, BBM popular because its a means of communication not because it is a “app”.

Jamaicans it seems are not so interested in having smartphones, despite the competitive pricing arguments for Wireless 3G Data as noted in Ryan’s Geezam blog article entitled “LIME, The iPhone 4 And The Death Of The Blackberry”, as the Blackberry is still king here. - Lindsworth.

We Are Wagonists

Jamaicans like the things that they see their friends are using. Which are this point its the network that gives them the most freeness (see point 1), BBM and phones that offer them cool features out of the box. Added to this fact that the majority of Jamaicans are either poor or are pretending to be rich so they will spend their money on a phone(s) that they can afford or a phone they can save for without taking out a mortgage.

All touch screen phones are the same

To a Jamaican consumer, a cellphone falls into 4 categories: a budget phone, a RazR, a BlackBerry, or a touch screen phone. If you see one Android phone, you have seen them all, no matter how you choose to customize the home screen - its the same thing. Baring technical hardware details every android phone on the market is the same to the large majority of consumers. I once saw a sales representative try to explain to a middle aged woman that the phone she was looking at was in fact a Nokia and not a Iphone, it was hilarious, she was absolutely convinced that it was a iphone. There are also a few people who have a natural born “hatred” for touch screen phones - I am not sure why. Not to mention the people with 2 left hands and greasy fingers.

Jamaicans Like to be different

When I say different, I mean physically different, not merely shifting widgets around their home screen. Different as in some people like flip phones, phones that are thin, phones that come in different colors, etc. Now compare this to the iphone or android which basically are all touch screen phones with slighly different screen sizes and processors which are mainly differentiated by the frequent hardware and software release updates. Back in the day we used to call these updates "service packs". You see now the problem with Android is that once you get it in your hand they all appear to be the same phone to the average user - its a speed race.

Conclusion

Now I have nothing against the Iphone, the fragmented Android OS, or the Windows Phone 7 which is defective by design. Before Steve Jobs bucked the trend, touchscreen phones where seen as impractical and unresponsive - now in the present day the marketing has positioned them “god sent devices”. Next they will be pushing touch pads and e-readers, and then later this year "Ultrabooks" will be the must have gadget for tech professionals who have disposable income.

Breaking into the Jamaican market is going to take more than just big screens and Apps. You will have to provide a diverse selection of phones that are cheap to own, offer data-plans which affordable to the common man while gradually improving the network infrastructure. Distributors should focus on low-end feature phones, instead of the high-end, high cost and complicated smart phones that you have to “sync”.

There is always a new fad on the market, and with fads come lonely people looking for others to join their party. The masses may join eventually but some markets follow, while other markets pop dem own style and beat at a different drum.

p.s. JAMAICANS DO NOT SPEAK SPANISH AND IS NOT A PART OF LATIN AMERICA.

by owen () Post your comments on this article

Why Frameworks Suck (Articles)

2011-12-15 07:40:56

Frameworks are what they are, they will save you a lot of time when deadlines are tight and give you tons of free code and documentation to read. But as in everything there are disadvantages and advantages which is why you are reading this article today. This article seeks to outline some of the pitfalls of software frameworks in general. It touches a little on programming paradigms which are frameworks but they are all children of the same mother. This article is aimed at the experienced programmer, if you are a noob you will not know half of the things I talk about here so this article will be of no use to you.

From now onward when I refer to the word “framework” I am usually referring to frameworks that OTHER people write, not your own custom framework. I can’t see your framework but in most cases you know how it works while most other frameworks are magic. Also I am refering to frameworks built on top of another language because if you have no choice then you are pretty much stuck with no way out.

Frameworks are hammers

Some people seem to think that frameworks are the be-all end-all of programming. Frameworks are tools like a class, array, pointer, for-loop, hammer or a saw. You CANNOT use a hammer to make a hammer. It is not possible, you will always be limited to what the framework is designed to do - which in the case of the HammerFramework is to drive nails. To a framework nut EVERYTHING looks like a nail. You can spend years planning and charting you API and realise that it is pointless in a day. Frameworks solve a specific set of problems. It would be good if you just drove nails all day but sooner or later you will meet up on a edge case. This limitation will often only manifest itself years after the project has grown old and rusty and you they try to make some major change to how it works (I'm looking at you Apache STRUTS). At which point you realise that there is a invisible wall around around you, a new version/fad probably gets released and everybody quickly re-factors all their old code to match this new found version - totally forgetting the last 2 years of pain and repeating the mistake again.

Useless code

Few people realise that if you write all your code in a framework you will end up with code THAT IS TOTALLY USELESS. In a framework, code is a extension of the framework, everything written is dependant on some convention that somebody dreamt up while sitting on the toilet. Copy ten lines out and paste it into another language or app and try to run it - it won’t work or even be fixable. And what makes it worst is that each framework has it own set of little classes/functions that are unique to it. A model can be anything in any number of frameworks, there are often no consistent way of working with them.

Most programs written in frameworks are often TOTALLY REFACTORED when they are updated or moved around. I have functions that I had written 5 years ago that I am still using today - what about my framework code? Useless! Most of it is filed away or deprecated. This uselessness occurs because the code does not carry any of its own MEANING. All it was doing was pushing levers around, shifting pieces from one place to the next. The few places you do have actual business logic are often dwarfed by the share amount of infrastructure needed to hold it up. Re-factoring is something often used to to hide this side effect. This happens every time a new thing comes out or a new version! There are even tools that do it for you! But you will still need to go and look at every single line because nothing is perfect. This only happens with code that is written in a kind of framework, you will NEVER see people refactoring a for-loop, because a for-loop is a language construct it serves a SPECIFIC PURPOSE and carries MEANING. Frameworks seek to abstract as much meaning as possible away from the code. Refractoring and schema updates are a problem - NOT a solution.

Discourages sharing

During my research I read an article that pointed out something that I did not even realise; Frameworks discourage sharing! Say for instance I write a "contact us" page in an MVC framework, you would think that it would be possible to share it with another programmer using another MVC platform, right? No sir, because code that is written in a MVC framework is so fragmented that parts of it makes no sense outside of the framework context. Further more you end up with 3 or 4 files, then you realise that you will have to send the helper code as well, eventually you have to send the models, then the WHOLE PROJECT just to demonstrate how one part of the code works! What people don’t realise is that your code and your framework are married at the hip. You are not using the framework - the framework is using you to propagate itself.

Force you to do unnecessary work

Frameworks are self supporting, and they make programmers do unnecessary work. Instead of solving common programming problems, most frameworks seem more interested in giving extra things to do to distract you from actual problems. If you have a SQL injection problem they give you a NEW OOP Abstraction layer which replaces all your SQL. If you have a PHP in HTML problem they give you a whole NEW template language to learn that is a little like PHP but alot like HTML but is neither. If you have session state problem they give you a class structure that you have to inherit and extra functions you have to call to get your program to work. It would not be so bad if you could pick and choose between the features but they are often tightly woven into the framework mesh. By the time to get up to speed, you will have totally forgotten you initial problem. Its all a distraction, if you want to set up rules use a programming language that has those rules built in - not a framework.

I have used many frameworks and I often wonder why am I putting 2 files into this folder and 3 files into another folder? It is not because of some useful reason - ITS BECAUSE THE FRAMEWORK WANTS ME TO DO IT. obviously it would be too much work for the framework designer to figure out what is what, based on the code you write, which is why you are forced you into some kind of “convention”. Why can’t I do a CVM in my MVC? or a VVC in my VCM? It is because each framework is hard coding a set of rules which make it work. These rules/conventions in a framework are just another wall between you and the solution to the problem. Look out for these convention/rule hacks and you will be the wiser. Once you go outside the bounds, you are on your own. Hack the framework, extend it - its all the same thing. If you problem is unique or complicated even in the slightest be prepared to spend 5 years writing handlers and scaffolding to get the expected results.

Additional Overhead

Remember I mentioned earlier that the framework and you code are joined at the hip? Well when you program is finally done (if ever), look at the size of your program + framework. If your program is 500 lines and the framework is 1 million, then your program is 1 million + 500 lines of code. That framework is now apart of your program and all the requirements that come with it. Just accept it. Any changes to your program will end up being framework changes (especially since you code is meaningless). If the framework needs to run on 64 gigs of RAM on a cold room server then your program needs it too.

Suppose every page in your program had to have 5 files? Lets say you had 50 pages, that is 50 * 5 = 250 separate points of contact - not counting models, helpers etc. Worst case say you have 10 pages which share views and models with a random number of other pages. Anybody adding or removing anything thing from your program would either have to be YOU or spend a great deal of time looking through all your code, AND the framework you used to understand what effect the change will have. Oh, well, yeah you could run the unit tests, lol, or write some new ones. This is something you just have to accept, DO NOT FIGHT IT. Major changes to code written in a framework - no matter how well designed - often results in a total rewrite. See because you use a framework does not mean that your code is well written or easy to maintain. A bad program is bad in anything it is written in.

Limits Innovation

Lets face it, frameworks are training wheels - only people who ride small bicycles use them. Even the large scale riders are often using highly customized versions (at which point they are like training rockets), or are stuck on legacy versions because they are too afraid to spend millions of dollars to upgrade their entire system to the lastest version (or really don’t care to). If you have to spend all your time searching through a plugin directory for solutions to your problem then you are clearly a small bicycle rider. What makes it worst is that in 5 years you will still be riding the same bicycle.

The majority of the other framework users spend a year learning their framework before another version comes along to give them features that they couldn’t possibly implement themselves - why you ask? because it is the nature of a framework, its designed from end to end, you have to play in the little sandbox - again DO NOT FIGHT IT. Companies who realise that thier framework is holding them back often spend years hacking at the framework or hire some guys to modify it to fit edge cases but by then they would have gone so far off the reserve that they either have to spend big to maintain it or make a quick decisive blow to the head. The rest of use poor mortals just have to wait and hope that the framework gods smile on us, maintain backwards compatibility and our long awaited feature request gets put in the next major release.

Why use a framework?

Frameworks arose for two reasons; because programmers like to share, realised that some people need training wheels and just cannot learn how to keep themselves on the right side of the road without hitting the guard rails. Secondly, businesses and managers needed a way to industrialize the process of software engineering. If you have large teams of programmers with mixed proficiencies, 50% of which are below average, the best way to get reasonably good code is to have them all working in a framework. Give them a framework! The bigger the framework the better! Frameworks also make it easy to swap people out if they get too complacent, since it is easy to find somebody else who can learn the same generic framework and continue the work. So its a win-win situation. Based on how you look at it.

Conclusion

Find the right tool for the framework for the job, the smaller the better, because in the end everything sucks. Frameworks save time and money BUT will not make you write better code, in fact it may even make your code worst. A framework will not make your code any more readable, reliable or maintainable (its basically swapping one set of bad documentation, for another large set of bad documentation ). It is important to understand your choice of framework - how it works and avoid trying to shoe-horn everything into a single sandbox - that will only limit you in the long run. Look out for Framework Caveats. Document your code, KISS, try to predict what future enhancement you may need and do proper testing early in development. Do not be afraid to ask questions. Do not be a sheep. Test out edge cases early in development - even if you have no present need to do so. Always read change-logs when they are released and keep abreast of new developments in your framework. You never know when a new framework version will come out. Probably next year.

My next article will be on the future of frameworks and how they should actually work. Look out for that.

by owen () Post your comments on this article

E3 2011 sucks, plus Sony, Microsoft and Nintendo Sucks RANT (Articles)

2011-07-24 10:47:22

Posting this a bit late but watevs, I've been busy.

If I see another FPS I’m going to vomit all over my keyboard come on goddam it man can’t you bastards come up with any new ideas? How many aliens do I have to shoot with space marines before they are all dead and done with? its like World War 2 all over again.

And don’t get me started on the frigging HD PS2 remakes bullshit. Is that why I cannot plug my dam ps2 controller into my ps3? just so that I can play the same dam game over again in a so called HD? Obviously Team Ico isn’t working on this because they should be busy working on The Last Gaurdian….but wait they NEVER MENTIONED THAT!!! WTF?

My god EVERY game announced by nintendo is a remake of some shit. Where is my dam starfox and FZero? Why would I want to buy Zelda again - with new textures? Release skyward sword already damn it.

WiiU eh is a gimmick but it will sure be copied once it gains some traction. I'm not sure I'm ready to give up my gamecube controller support though.

PSP2Vita is the same old same oh from Sony's assbackward R&D department. I don't know what they pay those dudes to do but it certainly not innovation. Backtouch pad is the gayest thing since Anal sex and they showed one game that is gay enough to make actual good use of it. Fuck that shit. 250? lol, must be 250 down with a payment plan. That shit is going to last 2 hours on its battery, might as well plug it into the wall ALL the time.

I don't see why everybody is ragging on Duke like they have somehow grown up and gaming is some kinda art form. Shit, MW3 is a interactive movie that plays itself. Duke may suck in 2011 but it will still sell more copies than Just Cause 2 which in my opinion is the best game this generation.

by owen () Post your comments on this article

My initial impressions of google plus, and yes it sucks (Articles)

2011-07-10 08:40:19

I've been to the Google+ and I can tell you its worst than you thought. Its like google buzz if you add too many people and at the same time its like facebook if you add a few uninteresting friends.

The stark contrast between a flood of random information and nothing at all is going to be an even bigger problem this time around. Especially since people have been flocking to it like rats. You will get invites to google+ until you finally cave in.

Calling it a closed beta is pointless because if you have any connections at all on the internet then more than likely one of them will be a "whore of the internet" and will send you an invite proclaiming that plus is the best thing since slice bread. Especially if you already have a gmail account plus sends emails out like a machine gun.

I think the problem with google+ is that it tries to be and do EVERYTHING which leads to a cluttered interface of videos and comment streams, +1 buttons and share links. Why do I need a share button when I'm already inside the social network that I sharing everything on? Its probably just a font size issue but google+ still hasn't learnt anything from facebook's font choices.

And for the people who don't think the interface is cluttered then I guess you have not noticed how many random popups there are. Popups are EVERYWHERE! you could be just minding you own business clicking on a regular link and the plus interface will decide that it need to pop up a wizard to ask you a bunch of questions - they are all over the place, questions, questions, questions, half the time you donot even know what you are agreeing to. By the end of the day you will have signed up to every application/company that google has made or bought out.

In the long run it may get better over time and its always good to give the "I can do and change whatever I want" facebook overlords some competition. But I think Google plus started off on the wrong foot; they threw everything into a bucket just to see what dies first, hopefully the whole thing doesn't infect itself and die. My opinion: scale back everything; the video links, the magical popups and bring the interface to a point of simplicity instead of trying to be a jack of all trades; twitter-facebook-flickr-myspace-digg-delicious clone.

by owen () Post your comments on this article

General Theory on Dreams and why they are always weird (Articles)

2010-03-26 15:05:57

I have always been interested in the inner workings of the brain. Being a programmer, I spend a great deal of time thinking of ways to create different systems of solving problems. This article is about a theory I have about dreams and why human need to have them.

Dreams are a succession of images, thoughts, sounds, or emotions passing through the mind during sleep. The content and purpose of dreams are not fully understood, though they have been a topic of speculation and interest throughout recorded history. The scientific study of dreams is known as oneirology.

Why do we dream?

The consensus is that you dreams because you are asleep and you brain needs something to do in its idle time. Which makes sense because we spend almost half of our lives asleep. "Sleep in humans, other mammals, and a substantial majority of other animals that have been studied (such as some species of fish, birds, ants, and fruit flies), regular sleep is essential for survival."

the nature of dreaming: that it is regular nightly, rather than occasional, phenomenon, and a high-frequency activity within each sleep period occurring at predictable intervals of approximately every 60–90 minutes in all humans throughout the life span.- wp

The Theory

My theory is that dreaming is not simply "busy work" being done while the body is sleeping but I think the brain is actually running a series of comparison tests across the information it has learnt during the day and in the past. The brain not only "thinks" at the point when there is a problem to be solved but actually is making up problems to think about when you are asleep. This is why we dream.

Dreams and learning

The assumption that the brain is running tests on you during your sleep leads me to imply something else about the brain. If my hypotheses that dreams are tests is correct and the fact that a dream is mostly a none physical activity, then it leads me to assume that there would be no benefit to running these tests unless it is a very necessary part of learning.

But then again if you are learning while you are awake why would you need to learn while you are asleep. I think the reason for this is because the brain is not one BIG computer but infact multiple little computers each doing its own thing, constantly changing while you are awake and gathering information. It would seem that it is while you are asleep that the brain gets a chance to run tests on the information that is gathered during the day.

These tests maybe some sort of maintence process. In my own experience my dreams seemed to always be a mishmash unrelated information, people and places. It is as if my brain is comparing scenarios, events, people and things I have learned in unusual ways to see how the "sub-brains" will react to it. I imagine that nightmare occur when the brain runs a comparison on something that is feared by the person. It also seems that these comparison tests/processes are not limited to current previous but can involve anything learnt or experienced in a person's lifetime. I could go further to guess that at one point or the other, everything learnt is tested against everything else in a constant sifting and sorting process.

I can only speculate on how the brain determines when a test is successful or when it has failed. Though often times a person will find themselves in a deja-vu situation. "Déjà_vu is the experience of feeling sure that one has witnessed or experienced a new situation previously (an individual feels as though an event has already happened or has happened in the recent past), although the exact circumstances of the previous encounter are uncertain.". Usually a person will only encounter "good" deja-vu scenarios and will seek to avoid any scenario which "feels" wrong or invokes some sort of fear emotion.

A Comparison Engine

Maybe there is no right or wrong, true or false scenario. There is a chance that the brain is in fact not a computer but in fact a complicated comparison engine which is updated during the sleep phase of our life. This might explain why we spend so much time sleeping. And further more explain why we have to sleep so frequently. The brain as a comparison engine would explain why people who are taught the same thing often think about them in different ways depending on their perspective and previous experiences. This would mean that if there was a way to raise 2 people, teaching them exactly the same information and exposing them to the same situations independently, then they should have the same dreams.

Conclusion

This Theory has lead me to speculate that the brain is not simply a big computer, running a single big program but infact a series of independent, parallel, micro programs, all learning and changing at the same time without any sort of uniformed synchronization. There are no consistent rules as to the structure of each program or how it interacts with each other part of the brain - it is not a network in the traditional sense but a pool. Apart from the parts of the brain which are hardwired for specific tasks, all the other cognitive parts of the brain must then be running at kernel level, at the same time, independently and yet cooperatively casting votes at the same time. In the sleep state the brain allows the normally independent processes to interact which results in dreams. Dreams which help to create bonds and links between thoughts and processes which are normally too busy consuming information while the person is awake. If this is truly the case then computers of the future need not only be able to think but also to dream. Because it is in the dream state that the brain does its best work.

by owen () Post your comments on this article

Verbal Diarrhea (Articles)

2010-02-12 15:20:04

Ah, some people just don't know when to STFU. Seriously.

This whole John Mayer situation, eerily reminiscent of several Kanye West situations, has me wondering why people just can't think before they speak. Especially when you're someone in the public eye.

In one interview this man:

- Kiss and told about several famous women he slept with

- Used a racial slur

- Admitted his penis was a white supremacist

- Offended women (black, white, yellow and brown) with his stereotypes

- Defamed Kerry Washington...

Do I need to go on? I hope everyone will have an equally long memory for John Mayer's transgressions as they did for Kanye West's.

This is a good assessment of the interview: http://ow.ly/16rBz

by SE (memoirsofadater.blogspot.com) Post your comments on this article

Video Games: Better graphics vs Better Gameplay (Articles)

2009-08-03 17:00:56

In my view the reason we can't have both is because development resources are always limited. Probably only the first party companies (sony, nintendo, microsoft) have infinite resources to spend years and pay the most talented and imaginative people to built their games. Which is why first party games always seem to come out with games that are excellent in all areas.

Now let me list the reasons why normally we can't have excellent graphics and excellent game play on limited resources;

Better graphics means; bigger textures, more processing power needed, more assets, more art, more physics, more motion capture, more sound samples, more video

Better Gameplay means; More options, more NPCs, more characters, more objects to interact with, branching paths and story, more actions, better A.I.

Now lets try to combine the 2;

Graphics over gameplay leads to; small maps, Flat A to B stories (most Fps games), limited interactions or Quicktime events, buses crashing into intersections that BLOCK YOUR DAM PATH!(uncharted 2 video) Big open spaces with nothing to do in them (ala Just Cause). Enemies that always spawn at the same place. Switchs.

Gameplay over graphics lead to; Old Games like Mario 1, PacMan, Zelda TTP, Time Splitters. Because really they had no choice but to make the gameplay solid (old and multiplatform games seem to suffer from this). I'm finding it really hard to find examples for this nowadays.

Conclusion

My examples are limited to what I can remember now. Either way what is needed is a balance between graphics and game play. Something like NMH, or FZero Gx (yeah the other racers on the track look shitty but they were 30 of them so it kinda balances out). Most games nowadays are shitty because the graphics department has more power and is therefore using up too much of the systems resources. hence forcing the gameplay/stories to be implemented inadequately.

by owen () Post your comments on this article

Programming: The downsides of Modularity (Articles)

2009-06-04 21:15:37

There is a common misconception that modularity is inherently a good thing. In fact modular systems are not optimized for performance and are often harder to maintain depending on the extent of the modularization. It is similar problem as OOP which as a drastic effect on the program as a whole. Once a modularization technique is chosen it usually affects the entire program permanently crippling it is not properly implemented. Modularity similar to OOP is a useful tool in the appropriate context. One should not start writing a modular program. However one should anticipate the areas of the program which will benefit from being modular.

Lets us look at a simple example 1;

start program

print("-- Add 2 numbers --");

print("Enter first Number:");

firstnumber = readkeyboard();

print("Enter second Number:");

secondnumber = readkeyboard();

result = firstnumber + secondnumber;

print("Result:" + result);

end program

As you can see the Example 1 is pretty simple and efficient. What I'm going to do now is redesign the above program in deferent stages of modularity. What you will notice is that as the program becomes more modular it becomes more complicated and at the same time less efficient.

Lets us look at example 2;

function acceptnumber( screenmessage )

print( screenmessage );

return readkeyboard();

end function

start program

print("-- Add 2 numbers --");

firstnumber = acceptnumber("Enter first Number:");

secondnumber = acceptnumber("Enter second Number:");

result = firstnumber + secondnumber;

print("Result:" + result);

end program

In example 2 we have introduced a function called acceptnumber() which allows us to reduce the amount of lines in the main program by moving the repeat tasks of printing a message on the screen and reading the keyboard from the user.

Lets us look at example 3;

function acceptnumber( screenmessage )

print( screenmessage );

return readkeyboard();

end function

function do_addition( num1, num2 )

return num1 + num2;

end function

start program

print("-- Add 2 numbers --");

firstnumber = acceptnumber("Enter first Number:");

secondnumber = acceptnumber("Enter second Number:");

print("Result:" + do_addition( firstnumber, secondnumber ) );

end program

In example 3 I've moved the code that does the add calculation into its own function called do_addition. do_addition accepts the 2 numbers that need to be added and returns the result. I've also go ahead and gotten rid of the result variable since its not really used for anything important.

Lets us look at example 4;

constants = array ("-- Add 2 numbers --", "Enter first Number:", "Enter second Number:", "Result:", "addition" );

function acceptnumber( screenmessage )

print( screenmessage );

return readkeyboard();

end function

function do_addition( num1, num2 )

return num1 + num2;

end function

function get_data_input(settings)

print(settings);

input1 = acceptnumber(settings);

input2 = acceptnumber(settings);

return array( input1, input2 );

end function

function get_calculation_output(settings, data_array)

if( settings == "addition" ) {

return settings + do_addition( data_array, data_array );

}

return "no work or invalid settings";

end function

start program

data_array = get_data_input(settings);

output_text = get_calculation_output(settings, data_array);

print(output_text);

end program

In the 4th and final example I when all the way and separated the input of data from the output and calculation. You maybe able to see various advantages and disadvantages of this method but it was done to demonstrate my final conclusion.

Conclusion

As you can hopefully see, all four examples do exactly the same thing, except each one becoming increasingly modular, less efficient and more complicated. I could have done a 5th step and implemented it in OOP but by now you should be able to see my point. A program can be simple without being modular and on the other hand be modular but VERY complicated. A program being modular does not mean that it is simple. And a modular program is not necessarily more readable than a simple program.

by owen () Post your comments on this article

Programming Theory: Throwaway Code (Articles)

2008-11-23 23:55:32

In today's age of new programming languages, frameworks, templates, RAD tools, MVCs and things that pretend not to be MVCs. A new productivity demon has emerged. Marketing is promoting easier and easier ways of rapidly creating stable enterprise applications that basically write the code and make your tea at the same time. At the same time when the adoption rate for the new paradigm is low they seek try desperately to win over new and old programmers with exciting new buzzwords without offering any really new solutions to old problems. Programmers are spending an incredible amount of time writing what I have coined as "Throwaway Code". Often referred to as scaffolding though this not directly what I;m referring to in this article. This article is largely about code lifespan, reuse and its general usefulness in future projects.

The "Throwaway Code" that I'm referring to is the code that;

exists for no other reason except because of some lacking feature in your language. aka The missing feature.

is tied to a specific framework and will be useless once they find a better way to do it. aka Framework Hacking.

is useless design pattern code. aka Getter Setter

gets boring fast. aka Model Boredom

Now I will explain each of these scenarios.

The missing feature

No programming language is perfect and anybody who says that their programming language is perfect clearly has not written enough code to have a clear understanding of anything that can be considered "perfect". Each language has their strengths and weakness. There are often times that you get stuck with a language such as COBOL and you have to write a million lines of code just to print out a table. When in a different language the same code could be written in 5 lines. There are times when you can hack your way into the language in order to get what you need but this is not always possible because sometimes the feature you require would need to be well supported at the lowest level of the language. You will only notice instances like this if you have experience with other languages otherwise ignorance is bliss. Time spent casting variables that the compiler has sufficient knowledge about could be spent writing ACTUAL USEFUL NEW CODE. In time the language will implement the feature and your hacked code will be a memory of times gone by.

Framework Hacking

I often look back at STRUTS 1 and wonder how could anybody EVER think that that was a good ideal? Though when you think about it frameworks are written by humans and humans make mistakes from time to time. Point is all that struts 1 code is now useless. Besides the things you learn from it, the code itself is useless out of its "struts context". All those lines of code are now replaced by newer, faster and smaller code. Very little of it can be safely ported into something else. So basically that code you spent hours carefully putting together is now trash, "throwaway code". Even the sections that you had cleverly custom hacked/coded where all in vain because they were all tightly tied to the framework, solving problems OF the framework rather than problems that evident in the wider scheme of programming. This is another point to note when it comes to frameworks; alot of time is spent hacking at the framework, it cannot really be seen as programming but more like patching holes in a pot. Because if the pot was good at the beginning then your time would be spent writing LOGIC CODE as opposed to hacking/scaffolding problems in the language. Of course

you may say programming is all about hacking away at useless things for hours on end trying to solve a problem. However when your hacking away at scaffolding do you really learn anything? Except maybe the intricacies of a not so perfect framework?

Getter Setter

Now the problem of useless design pattern code seems to be popping up ever so often nowadays especially in OOP. OOP seems to be eating alot of its own dog food. I tend to see the programmer writing code for no other reason than to make it easier for the tools that they use, so that the tools can generate more code for the programmer to write. I've mentioned this before. Point is depending on where you are in the evolution of a language/framework there is alot of code that you'll be writing "just-because". I remember concatenating strings in C. Although ignorance in bliss, there are things that you really don't need to do. Having to cast-type the same thing 4 or 5 times in the guise of improving maintenance and extensibility is nonsense, its redundant. There is always a better way to do things. It often becomes evident after the language is replaced with something new. At this point there is a great enlightenment "omg version 3 is so cool". But no one will admit that version 1 sucked all hell - ESPECIALLY when its just out of beta. Its not even about evolution, certain basic programming paradigms are being ignored or hacked around. Singletons anybody? Even auto generated code has crazy drawbacks and redundancies that pop up only during maintenance.

Model Boredom

I've only noticed this in one case with one particular language. It seems that with MVC programmers become obsessed with creating a web of models, deleting them entirely and then re-creating them again. As if they are never satisfied with the model OR maybe its just too boring to update OR some new feature comes out that requires a total re-thinking OR maybe they are just get sick of it entirely after a year of playing with it. These model changes are usually not evident because the output is usually not affected. I will have to look into this more but your opinions on this topic are welcome.

Conclusion

Programming is becoming more and more abstracted and as a result much of the code written simply exists as scaffolding. Soon to be replaced by the next big iteration or framework bug fix. In reality it may be nothing new, a right of passage or growing pains. But one thing is for sure; the bigger the API - the greater the chance that 90% of your code will end up in the recycle bin or frozen in time, waiting to be re-factored.

by owen () Post your comments on this article

Managing complexity in Software Development (Articles)

2008-09-26 10:56:20

In programming, sooner or later you will come up with a solution to a problem that is somewhat "complex". The said solution may be advantageous to the program in various ways. The thing to note is that you should ensure that his complexity is "contained". Far too often software developers let a complex solution to a simple problem seep in to the body of the program itself. As a result making the entire program unecessarily complex. Miracle solutions are proposed to increase productivity through various catch words that end with "-ibility".

For example the index page of my website is probably the most complex page in the entire website. Yet the website itself is quiet simple. The index page was not quite as complex as it was now. Originally it was a series of IF statements that directed the visitor to a requested page based on various parameters. IF PAGE == ABOUT THEN LOAD ABOUTPAGE. It was really REALLY simple. One day I realised that if I could find a uniformed way of determining the next page then I could replace all the IF statement was a controller or MVC (as they call it now a days). The new solution required careful thought.

As with every line of code or function created there are things to consider;

How is changing this page going to make the other existing pages BETTER.

How is changing this page going to make the other existing pages WORST.

how is changing this page going to affect the quality of code as a whole.

Will changing this page make the other pages more complex or less complex.

These are important points to consider when dealing with complexity. You should always beware of things that may unessarily complicate the entire program offering shortterm benefit but long term headache. If I had suddenly woke up and decided to change the index page to use a random MVC without considering how the actual MVC would affect the complexity of the program itself then I would have made a grave mistake which leads to people discontinuing software a year after it was implemented.

All things must be considered in light of the shortterm and the longterm when developing software. A piece of software that starts out complex will not get simpler as you develop it.Keep the simple parts simple It will only get more complicated until it collapses under the wieght of its own complexity. In the same light something very simple can be complicated by a misplaced bottle neck in the system that was implemented on a "whim". Implementing features on a "whim" or ad hoc without considering its benefits is the fastest way to complicate what was once a simple program. Keep your eye on the important parts of the program to ensure that it remains simple and that any complex algorithms and concepts are "Functionalized" away from the program's core purpose.

In the case of my index page (which loads all the other pages) it may seem to be against what I just said - a very complicated concept deep within the core of the application. The thing to note is that the index page itself is a FUNCTION. What it does is completely independent of the program. It can easily be replaced because the other pages are not affected by it, nor thou or both shall go with him. hmmm. It is a function. An important function but a function none the less. The other pages on the site are unaware of its existance and so are not affected by any low level changes that I make to it. The sub pages behave as if they are in a vacuum, unaffected by the index page. It is not a typical MVC that seeks to solve a problem by controlling/limiting structure rather than providing a genuine solution to the structure problem.

What I could have done and what most people do is make the index into a class. And then enslave other pages into a "house of cards" situation. Now instead of isolating the solution to a problem of IF statements - the programmer ends up complicating the entire program in order to simplify it. I am not saying that wide spread refractoring is not necessary. I am saying that the inplementing complex solutions to a problem should not be allowed to complicate the program as a whole. Find a way to solve the problem without creating thousands of little problems/new workflows in the progress. Alot of this is explained to more dept in software engineering anti-patterns

Now for the code.

Here I will list elements that add complexity when writing programs;

IF THEN ELSE Statements: Avoid having a catch all "else" statement. Usually it leads to logic bugs and poor clean up.

Avoid unecessary class implementations: There is nothing more annoying than having to do a "new" every single time you want to use a base class. Its pointless. If you only need one instance at a time why is it a class? Make a single function that manages itself. Always ensure that you know the ;why" behind everything you program so that you can better make it when it needs to change.

Avoid giving yourself future work or more per-module work: Now I understand that some people like the whole "house of cards" thing but really now. It is easy to copy development documents off the internet and pass then off as your own but hard to implement something that you have no expirence in using.

Avoid doing the same thing over and over with slight per-module changes: This is a another sign of a train wreak waiting to happen. Sooner or later you are going to have to refactor all those slight changes and you will realize that 3 lines at the top of every module was simply there to make you feel productive but added nothing to the program.

Avoid tight coupling of you classes. This often occurs by using checked exceptions to force calling processes to handle them. Hence causing every calling program to be tied to a useless/decorative exception tree of choas.

Avoid eating you own dog food: I cannot stress this enough.

Avoid fragmenting processes: There are times when you may be tempted to create a function for the purpose of simplifing a process. This usually happens when you have so much code that its difficult to really keep track of what is going on. In such a case avoid creating singleton functions that look like functions but are infact big GOTO statements. These singleton functions usually have to be called in a specific order and a specific custom object has to passed to them. Its better to just keep it all in one function with good documentation. Ten random singleton functions are neither helpful nor do make the program easier to read/manage.

Avoid classes with too many setup functions: Some may think its a good idea but classes should manage as much of its internal processes as possible. Avoid;

c = new calc class;

c.setid(10);

c.setname('test');

c.getdata();

c.getresultset();

ans = c.calculate();

Its better to create a function called ans = calculate_test(10, 'test'); Not only do you have less lines of code (per call) but the test calculation process is encapsulated.

Avoid try-catch-throw logic: if a function is boolean it should return true or false. It shouldn't throw random exceptions to the calling function. Try-catchs are often used as a lazy form of IF-ELSE. Situations like this should be avoided for the same reason as mention before.

Avoid bandaid errors, hiding errors and non-specific error messages. A system is not secure if its errors need to be a secret. Having clear error messages allows for quickly identifying problems during the development and testing phase and evening during the life of the system. Searching through log files for errors that could have been easily displayed to the user is a waste of time. Critical errors can be missed that are hidden for years in log files and catch statements. The last thing you want is someone to be calling you in the middle of the night about some program that you wrote 5 years ago. Assume All errors are fatal!

Assume all errors are fatal. Often times errors are ignored or logged at lower levels of the program and the program is allowed to continue. This is often done to prevent the program from crashing. PROGRAMS CRASH its what they do when something is wrong. It is more important in program processes to identify WHEN a error occurs as opposed to the order. Log files are good are error order but poor for edge case event errors.

Conclusion

If your going down the wrong road it never too late to turn back. A poorly written program is only good as long as no one knows about it. You can throw as much RAM or HARDWARE at it as you want. Sooner or later it will get replaced by a off the shelf software that is probably JUST AS BAD OR WORST THAN your custom developed software. And the software you wrote will be just another skeleton in your closet. The main difference will be that the off the shelf software has learned to manage its complexity, increase flexibility while meeting user requirements.

Often times there is nothing you can do but to just run with what you have, make as much documentation as you can and pray for the future developers.

by owen () Post your comments on this article

Hardwiring: programming the design (tech) (Articles)

2008-03-24 20:22:45

There is a tendancy to write your use case directly into the low level design of the code. This pattern should be avoided as much as possible because it results in extensive "recoding" whenever high level design changes are made to the program. The highlevel design is not caved in stone and will most likely change as the system evolves but its core design rearly changes. It is important for the programmer to identify this core design.

For example an extreme case can be seen when the previous programmers wrote a screen for the 10 department types that are in the system - assuming that there would only be 10. As you can see hardcoding or hardwiring your use case rules into your code is not a good thing. The programmer wrote the code on the "business logic" instead of the "system layer".

It is important to notice that there is a system below the business logic. This system is what keeps the application simple and stable. The programer should seek to find the best way to rewrite the highlevel business logic into a stable sub system.

Take for instance the previous example: you can imagine that the programer got a use-case with 5 rows and 2 column of 10 items. The programmer looked at the first line of the use case and started coding right away (and in truth and in fact probably coded it in half the time that I would take to code it). The end result will work and will have the same output but the difference between the 2 approachs to the problem is night and day. Further down in the project the need MAY arise to add a new type of department. You should notice that the business logic in the use cases DOES NOT BREAK but the code that was written to implement the use case fails and the blame goes on the programmer even though the programmer did what the use case said should be done.

Another example: bank type. You notice that the use cases specify particular actions that occur on certain types of banks. And these types of banks are hard coded into the system. Business logic constants are bad design. This implementation is done like so:

BANK_TYPE1 = 1

SELECT * FROM BANKS, BANK_TYPE WHERE BANK.TYPE_ID = BANK_TYPE.ID AND TYPE =

IF BANK.TYPE == BANK_TYPE1 THEN

DO BUSNIESS LOGIC

END IF

The shortfall of this type of programming is the SAME as the 10 item example above. If for instance a new bank type is added that implements the same business logic as that of BANK_TYPE1 then the code will have to be CAREFULLY altered to facilitate the change to the design. Here is the new code:

BANK_TYPE1 = 1

BANK_TYPE_TWO = 3

SELECT * FROM BANKS, BANK_TYPE WHERE BANK.TYPE_ID = BANK_TYPE.ID AND TYPE = or TYPE =

IF BANK.TYPE == BANK_TYPE1 THEN

RETURN (BANK_TYPE1) BUSNIESS_LOGIC1()

END IF

IF BANK.TYPE == BANK_TYPE_TWO THEN

RETURN (BANK_TYPE_TWO) BUSNIESS_LOGIC1()

END IF

In the best case senario the same programmer will be able to remember how the program works and change all the places that need to be changed to fix the problem.

The solution to this problem requires a system level design change that will protect the code (the programmer) from changes/enhancements to the design. There are many ways that this can be done and the best way often takes more time and therefore the benefits of such an change must be evaluated during development by the programmer.

---

The point here is that it that the use cases are not low level designs. The progammer should ( whenever possible ) try to abstract the effects that changes have on the code which is written, by writing it in a way such that it is flexible enough to absorb business logic/design changes that may occur in the future.

by owen () Post your comments on this article

How to tell if you are an IT person (Articles)

2007-11-25 19:47:55

Mesha this is for you. I will try to keep this simple and to the point because some of us like to argue and some of us don't. I will start out by listing the qualifications that either by themselves or combined will result is a person who can call themselves a techie or an IT person. This article is written because I've realized that now in Jamaica since it seems that people have started to call themselves "IT persons" without fully clearing the bits or understanding what it actually means. By IT I mean "Information Technology" or Computer Science or whatever related field you choose. So here now I start with a list.

You are and IT person IF;

You like lists.

You like to play games for long hours, develop habits easily and have at some point in your life completed a mario brothers game. Though not necessarily beat the game but have tried on multiple occasions. This is however not limited to video games but anything involving a winner and a loser such as card games and games of luck or skill. You should be able to play many games at least 3 - not just one that somebody taught you. And be up for playing ANYTHING that looks like a game that you can win. Games can include mind games, board games, random text messaging. Solitaire is not a game.

IT people like to solve problems and hate doing the same thing twice. If an activity doesn't solve some kinda problem that will save somebody "work", time or money then more than likely you are a "packer". If you've done it before and are still doing it without improvement then you can't see the rabbit.

If you are disgusted by the behaviour of IT people and think that they are lazy, selfish and inconsiderate then you are most definitely not an IT person.

Having an IT degree or qualification or working with computers or teaching does not automatically give you the right to call yourself and IT person. You merely "associate" with IT people but you haven't crossed that line where you start avoiding people and not returning calls.

Working at an IT company doesn't not make you and IT person.

If you ever reach to a state where your too busy to brainstorm a solution to a problem or have a concept in your head that is called "work" such as can be compared to farming, manual labour or mining coal - then more than likely you are in it for the money are not an IT person but rather a slave to the money. Go and follow your dreams. No matter how far down the wrong road you've travelled - its never too late to turn back.

IT people do not like to use powerpoint or write lengthy essays. If you like to write multipage essays then chances are you are not an IT person.

Most IT people that I know like what they do, it might not seem that way but its true. On the other hand if you would rather be flying around the world, teaching kindergarden, or staring in a rock band then chances are you are not an IT person.

If your monitor is set to 800x600 then I really don't know what world your living in.

If you are confused or fail to see why I would list these things are behavioral patterns of IT people then chances are you cannot relate and are NOT AN IT PERSON.

This list that I have compiled more than likely is not complete and millions of ways could be found to argue around it. Whether depending on whether you are a woman or a man or your from the country or whatever - it doesn't really matter because most people either are who they say they are or are pretending to be a doctor. To each his own.

by owen () Post your comments on this article

Quick: How to setup and run php-apache on win2k sp4 (Articles)

2007-07-01 15:17:15

Friday, May 18, 2007, 7:15:29 PM

"for people who have installed something before"

goto (link)

download the last "PHP x.x.x installer" it should be about 22 mb by now. Php has 2 streams; a 4.x stream and a 5.x stream. Check which version your web host will give you access to. If your only going to play with it on your machine then just go for the lastest version. But remember that if you start using features of 5 you might have a little difficulty running it on 4.

Downloading the Apache HTTP Server

Go to (link) and download the "HTTP Server". Which also has 2 streams but the instructions above still apply.

Start installing

Install the Http Server

Install Php

Run the php Installer. It might ask you to setup a server for ex appache and select the folder which contains the configuration files ( C:Program FilesApache Software FoundationApache2.2htdocs )

Do not enable all the php modules, pick the ones that you know you want because sometimes the modules have external requirements that may prevent you from starting,

Got to Start//Programs//Apache and then search the option to restart your http server.

Installation Done

Goto

C:Program Files/Apache Software Foundation/Apache2.2/htdocs

create a text file

call it "p.php"

Edit it with a text editor (preferable editplus from (link) )

add this code to the file;

phpinfo();

save the file.

OPen you browser and goto;

(link)

You should see a long purple table with the php logo. Your good to go. Setup was successful. That directory is now your webserver, so can only run php programs from the for now.

More stuff to do

(link)

►Another problem is that people many times use OLD PHP script that uses 'short tags'. That is when the PHP declarative starts with

Other

You might also want to install a database such as Mysql

If you run the Mysql 5 install do not enable "strict mode". Its really really really strict.

Might also want to get phpmyadmin

by owen () Post your comments on this article

Gene find triggers baldness hope (Articles)

2007-05-22 06:51:01

Hair loss in humans might be reversible, suggest scientists who have helped create new hair cells on the skin of mice.

It was thought hair follicles, once damaged, could never be replaced.

But a University of Pennsylvania, US, team, writing in the journal Nature, says hair growth can actually be encouraged using a single gene.

by mad bull (www.madbull4.net/) Post your comments on this article