Some thoughts I've had.
It helps keep things on track. The short iteration times, documentation, and emphasis on working "demos" at the end of each cycle means something can't get too out of hand.
I wish I had known about that evidence based scheduling towards the start. It really shows how to create good time estimates, even without the simulating you have info. Plus, it captured the whole idea of concrete "what needs to be coded in the next x hours" stuff that I think the system my team used missed
If you're going to introduce agile development, introduce it in multiple classes. A single semester gave me and my team a basic understanding, but a multi-semester learning process would have helped me learn it better and use it much better in this class.
Friday, May 13, 2011
You are a software gardener, not a software engineer
An interesting analogy I came across, with a bit of a rant, found here.
Some of the highlights:
Don't expect to know where every leaf will fall when you plant the seed.
Environment matters, both in where it's being designed and where it's being sold to.
Gardens will grow weeds. They are never "finished". They need to be maintained
The quality of the gardeners matters a great deal.
I think it's an interesting read. How true it is...well, that's something I'll only be able to tell with experience over the years.
Some of the highlights:
Don't expect to know where every leaf will fall when you plant the seed.
Environment matters, both in where it's being designed and where it's being sold to.
Gardens will grow weeds. They are never "finished". They need to be maintained
The quality of the gardeners matters a great deal.
I think it's an interesting read. How true it is...well, that's something I'll only be able to tell with experience over the years.
Decorating, and Facades
The decorator design pattern is what we have seen as a wrapper class. Take some class, wrap an instance of it, and add some functionality. It's a form of delegation in the cases of the old class's functionality.
Facade design pattern is about putting forth a simple, common interface to several sub-systems.
Facade design pattern is about putting forth a simple, common interface to several sub-systems.
Abstract Factories
The Abstract Factory pattern is an abstraction of creating related objects (such as subclasses of some abstract class) without having to directly specify what class. This is done by creating a static method (possibly within its own class) that uses some state to decide which type of object to return. By doing this and having the calling program influence this state, decision of which implementation can be put off until runtime.
Using SVN Repositories part 4: Merging and Reintegrating
Merging from Trunk to a Branch: So you've been working on your branch, and they've been working on the trunk. You want to merge their changes into your branch so it doesn't drift too far from the original. This is done with the merge command, which is used as "svn merge URL" where URL is the url of the trunk directory. Just like with updates (only more so), you have to resolve conflicts and make sure things didn't break your changes. Then you just commit, and it commits to your branch directory. SVN will even keep track of what was merged
Reintegrating your branch.
first, merge any changes from the trunk, test, and commit. Then, switch to the trunk. Reintegrating still uses the merge command, but this time from the branch directory and with the --reintegrate flag, which is needed because the branch is a combination of branch-specific updates and merges from the trunk. It tells SVN to just look at the differences between the HEAD of the branch and the trunk.As with merging in the other direction, you'll want to check nothing broke before committing the result.
That's all I'm going to cover in this mini-series of posts.
A more complete guide can be found here
Reintegrating your branch.
first, merge any changes from the trunk, test, and commit. Then, switch to the trunk. Reintegrating still uses the merge command, but this time from the branch directory and with the --reintegrate flag, which is needed because the branch is a combination of branch-specific updates and merges from the trunk. It tells SVN to just look at the differences between the HEAD of the branch and the trunk.As with merging in the other direction, you'll want to check nothing broke before committing the result.
That's all I'm going to cover in this mini-series of posts.
A more complete guide can be found here
Using SVN Repositories 3: Branching and Switching
This is a big one, and something I think would have been nice to see in earlier classes.
Why you want them: Simply put, to minimize disruption. Say you want to take a module out and add new features, and it would leave broken while you were working on it. Instead of creating that disruption, create a branch and work on the feature from there
As it turns out, branches are more or less copies, and in fact are made by making copies of the files and putting them in another area (usually done on the server because the way the files are represented letting it be much faster there). But they're SVN copies. That means that they share the revision history of everything before the split.
Quickly switching between branches:
The svn command makes a working copy reflect a different branch, as well as effectively running an update. so using it in the root directory of your working copy makes the updates and commits go to that branch, allowing you to quickly switch between multiple branches. Where it starts to get odd is that you can set different directories to different branches.
Why you want them: Simply put, to minimize disruption. Say you want to take a module out and add new features, and it would leave broken while you were working on it. Instead of creating that disruption, create a branch and work on the feature from there
As it turns out, branches are more or less copies, and in fact are made by making copies of the files and putting them in another area (usually done on the server because the way the files are represented letting it be much faster there). But they're SVN copies. That means that they share the revision history of everything before the split.
Quickly switching between branches:
The svn command makes a working copy reflect a different branch, as well as effectively running an update. so using it in the root directory of your working copy makes the updates and commits go to that branch, allowing you to quickly switch between multiple branches. Where it starts to get odd is that you can set different directories to different branches.
Using SVN Repositories part 2: Revision Keywords
Revision keywords:
These matter more if you're working from the command line although similar functionality is built into most GUI clients for places you use them. HEAD is the only one you'll be interested in when sending requests to the repository, and simply is the latest commit. The other three are used when looking at the working copy. BASE is the revision number of the local copy, COMMITTED refers to the last reversion number with a change to that file, and PREV is COMMITTED-1, referring to the version just before that change.
These matter more if you're working from the command line although similar functionality is built into most GUI clients for places you use them. HEAD is the only one you'll be interested in when sending requests to the repository, and simply is the latest commit. The other three are used when looking at the working copy. BASE is the revision number of the local copy, COMMITTED refers to the last reversion number with a change to that file, and PREV is COMMITTED-1, referring to the version just before that change.
Using SVN Repositories part 1: cleanup and locks
Most of us have, at one point or another, set up an svn repository for a project. Maybe it was a requirement, or was heavily recommended. But we just got by on the most basic stuff available. Commit, update. If we were lucky, we ran into a situation where we had to revert, and on occasion a team might have to deal with merging of a conflict. But what other functionality can SVN offer? And what exactly does that cleanup command do?
Well, to answer the second question, SVN updates to working copies behave similar to a journaled file system. The client will make a private "to-do" list of the actions it's going to take. Then it makes the updates, locking the parts as it's working on them. Finally, it releases the locks as it finishes each part and removes it from the todo list. If something goes wrong, that list is still there, and cleanup just goes through and finishes things, releasing any locks along the way.
Locks: you can lock svn files so that others can't edit it while you're doing so, but they're "soft" locks, very easy to break. Treat them as more of an additional communication measure.
Well, to answer the second question, SVN updates to working copies behave similar to a journaled file system. The client will make a private "to-do" list of the actions it's going to take. Then it makes the updates, locking the parts as it's working on them. Finally, it releases the locks as it finishes each part and removes it from the todo list. If something goes wrong, that list is still there, and cleanup just goes through and finishes things, releasing any locks along the way.
Locks: you can lock svn files so that others can't edit it while you're doing so, but they're "soft" locks, very easy to break. Treat them as more of an additional communication measure.
What makes a good software engineer
I found an article here describing the qualities of a good software engineer. Several of the points are similar to ones we heard in class. Some of the points that resonated with me:
Having a "right way" of doing things, and don't let it slip. Good quality, maintainable code is a result of this, and compromising just because you're short on time will likely end up bad
Be willing to suffer a bit trying to figure things out yourself before going for help. I think the class took this a step further with the whole "chain of command" idea, where you rely on yourself, then a little research, then your peers, then whoever's above you.
Never stop learning. This one kind of applies to all walks of life, but especially with a software engineer. There's always a new language, some new paradigm, a design pattern that makes things easier, more maintainable, or more understandable. We live in a fast-changing field, and it pays to keep up and keep ahead
Share that knowledge. A strong team that you had a hand in making is going to have more value than you alone having that knowledge. Keeping what you know too secret within your team just opens the way to over-competitiveness and backstabbing, neither of which is going to help the team as a whole
Having a "right way" of doing things, and don't let it slip. Good quality, maintainable code is a result of this, and compromising just because you're short on time will likely end up bad
Be willing to suffer a bit trying to figure things out yourself before going for help. I think the class took this a step further with the whole "chain of command" idea, where you rely on yourself, then a little research, then your peers, then whoever's above you.
Never stop learning. This one kind of applies to all walks of life, but especially with a software engineer. There's always a new language, some new paradigm, a design pattern that makes things easier, more maintainable, or more understandable. We live in a fast-changing field, and it pays to keep up and keep ahead
Share that knowledge. A strong team that you had a hand in making is going to have more value than you alone having that knowledge. Keeping what you know too secret within your team just opens the way to over-competitiveness and backstabbing, neither of which is going to help the team as a whole
Project Value Analysis
Cool projects are great, but any project in the professional world needs to have some value. This, as we heard during presentations today, is especially true with potential entrepreneurs. I found a couple of suggested points to keep in mind when considering this in an article here
1. Revenue generation from the new application
2. Cost reductions from the new application or upgrade
3. Indirect revenue generation
4. Increase in exiting user base due to some new features
5. Increase in market share
6. Revenue increase in companion application
It even explains why it might make sense to consider these when you're not directly involved with the selling and such. "Taking the business and value aspects into consideration during development enables you to view the project from the clients perspective. This in itself makes taking decisions regarding certain technical issues easier"
1. Revenue generation from the new application
2. Cost reductions from the new application or upgrade
3. Indirect revenue generation
4. Increase in exiting user base due to some new features
5. Increase in market share
6. Revenue increase in companion application
It even explains why it might make sense to consider these when you're not directly involved with the selling and such. "Taking the business and value aspects into consideration during development enables you to view the project from the clients perspective. This in itself makes taking decisions regarding certain technical issues easier"
Writing good atomic requirements
A good atomic requirement should encompass a few key points.
First, a requirement number. This allows easy tracking
Second, a brief description and what type of requirement it is (functional, aesthetic, etc)
Third, a rationale for implementing it
Fourth, what criteria will be looked at to judge it completed
Fifth, a priority
Sixth, what user story it came from
This allows all the relevant information of a requirement to be read at a glance. Imagine a 3x5 card
First, a requirement number. This allows easy tracking
Second, a brief description and what type of requirement it is (functional, aesthetic, etc)
Third, a rationale for implementing it
Fourth, what criteria will be looked at to judge it completed
Fifth, a priority
Sixth, what user story it came from
This allows all the relevant information of a requirement to be read at a glance. Imagine a 3x5 card
Delegation and adaptors
So you have this code you want to reuse. You can extend the class, inheriting not only what you need, but everything else along with it. In java, this also limits you, as you can only extend one object at a time.
An alternative is to make a class that delegates to the reused code.
An adaptor is a class specifically used in between legacy code with one interface and new code that wants another interface. The adaptor presents the new interface, effectively translating things and allowing the legacy code to exist within the new design.
An alternative is to make a class that delegates to the reused code.
An adaptor is a class specifically used in between legacy code with one interface and new code that wants another interface. The adaptor presents the new interface, effectively translating things and allowing the legacy code to exist within the new design.
What do unit tests and Agile Programming have in common?
Unit tests should be able to be run fast and often. Agile methods emphasize fast iterations. In both cases, the idea is that you find out mistakes quickly. And you will make mistakes.
Kangaroos with missiles, or Reusing code for fun and profit...but mostly fun.
Ah, the killer kangaroo story. Maybe you've heard of it, maybe you haven't. As the story goes, work was being done by the Australian Defense Science and Technology Organization's Land Operations/Simulations on a simulator for helicopter pilot training. It included, among other things, herds of kangaroos, since startled animals could give away a helicopter's position. “Being efficient programmers, they just re-appropriated some code originally used to model infantry detachments reactions under the same stimuli, changed the mapped icon from a soldier to a kangaroo, and increased the figures' speed of movement.
“Eager to demonstrate their flying skills for some visiting American pilots, the hotshot Aussies "buzzed" the virtual kangaroos in low flight during a simulation. The kangaroos scattered, as predicted, and the Americans nodded appreciatively . . . and then did a double-take as the kangaroos reappeared from behind a hill and launched a barrage of stinger missiles at the hapless helicopter.”
“Eager to demonstrate their flying skills for some visiting American pilots, the hotshot Aussies "buzzed" the virtual kangaroos in low flight during a simulation. The kangaroos scattered, as predicted, and the Americans nodded appreciatively . . . and then did a double-take as the kangaroos reappeared from behind a hill and launched a barrage of stinger missiles at the hapless helicopter.”
It makes a good story, and shows quite nicely that even when reusing code you have to be careful, but as it turns out, there's a bit more to the story, and it wasn't a mistake so much as a bit of fun. The kangaroos weren't there out of necessity, the interesting bug was discovered rather early, and the “kangaroos” were firing beach balls, the default weapon of the simulation code.
Initial story found somewhere on the net, the rest from the snopes article here
The Null Object Design Pattern
I came across an interesting design pattern recently. Say you have a service that fetches a foo object and calls foo.bar() if some condition is met. Under normal circumstances, you'd have to check if the foo object is null. What if, instead, you could have an object that represents a null foo, and just has no-effect methods. That way, the “null” object could be treated the same way as a normal object. To do this, just write a private inner class that extends foo, have its methods do nothing and return false on condition methods. The outer class will have a static final instance of this, and any outside methods that are supposed to fetch a foo then return this “null” object if they fail.
I found it here
Evidence Based Scheduling
Developers don't like writing schedules. They're a pain to write and often don't seem realistic. I found a system for writing them called evidence based scheduling. The complete description can be found here but here are the highlights:
1:break things down into small timeframes, no more than 16 hours. Large timeframes like days and weeks leaves what actually needs to be done extremely nebelous. With smaller timeframes you need to find out what's actually coded.
2: track elapsed time. Chart estimated time for tasks vs how long they actually took. This gives a nice velocity metric. Keep this 6 months back.
3: when estimating the time it will take to complete future tasks, run a Monte Carlo simulation assigning random values from the person's velocity history to each task. The estimates and their conversion to calender dates can be automated, and the averaging against the person's velocities will help give a better estimate.
Interesting enough, because of the way the estimates are calculated, interuptions to the coding time don't need to interupt the “clock” with elapsed time. The number of times that velocities where time taken involves one of those interruptions are used is very similar to the chance that those interuptions will happen.
4: manage the projects actively. You can see how cutting lower priority effects ship dates, estimate ship dates for each person, and use these to make changes
The method kind of reminds me of some of the artifacts used in SCRUM and other agile programming methods. I'm guessing something like this would be easy to integrate.
The Waterfall Development Method
One of the older development methods out there, the waterfall method specifies a single major iteration, starting with requirements analysis, then going through design, implementation, testing, release, and maintenance. Its has a few advantages, such as clear start and end points to each part, and improved quality because the specifications must be finished up front, helping prevent feature creep. There are, however, several major criticisms to this method. First, the requirements may not all be known at the start, but rather will emerge as the project progresses. Also, because there's no return to previous steps, what you have when you finish one is what you have. In some cases, you'll hit the implementation process and find out that there are roadblocks.
More reading here
UML class diagrams
UML, or Unified Modeling Language, encompasses several documenting diagrams, including ones representing use cases and sequences of interactions between the code, but one of the most basic, and the one that often first presented, is the Class Diagram. A class diagram gives a clear, visual representation of the class hierarchy and the interactions. It helps with planning a system, as well as being able to tell at a glance how things interact.
Test Driven Development
Test driven development, or the practice of writing the unit tests before writing the code. This means you have to know the requirements before you start coding, and in such a way that you can write a set of tests that encompass that specification. This gives a few interesting benefits. First, once you have the tests written, you have a metric to measure completeness of the code. The more tests passed out of the set, the closer you are. Second, during refactoring, you have a way to make sure you haven't broken the functionality tested.
Friday, May 6, 2011
How to write unmaintainable code
I found another "what to avoid" article cleverly disguised as "how to make things bad" related to programming. I like articles like this because they're memorable and funny, making it all the more likely for the concepts to stick. Sure, some of them are a bit out there (using a baby names book for variable names, camouflaging commented-out code), but others point to rookie mistakes (obvious commenting, ignoring coding conventions, not validating input), and suggestions to use features of languages like assert.
Article here
Article here
Friday, April 15, 2011
User Stories vs Use Cases, revisited
alt title: wikipedia isn't always right.
So after some concert being brought up about the correctness of my previous post for this topic, I decided to look into it a bit more. Here's what I found:
User stories are generally described as short or brief, but that is a guideline, not the point.
The most commonly named difference is that user stories follow the idea of a person wanting to accomplish a goal. Use Cases tend to focus more on the process used to accomplish the goal.
Information was found by googling "user stories vs use cases" (without the quotes) and checking most of the first page of results.
So after some concert being brought up about the correctness of my previous post for this topic, I decided to look into it a bit more. Here's what I found:
User stories are generally described as short or brief, but that is a guideline, not the point.
The most commonly named difference is that user stories follow the idea of a person wanting to accomplish a goal. Use Cases tend to focus more on the process used to accomplish the goal.
Information was found by googling "user stories vs use cases" (without the quotes) and checking most of the first page of results.
Wednesday, March 23, 2011
(One of the reasons) Why large teams don't work
So I recently stumbled upon an article that talks about why large teams have more trouble. The key idea he presents is "lines of communication". He shows the relation between team size and number of communication lines, then gives a few specific numbers. 10 lines for a 5 person team, 45 for a 10 person team, 190 for a 20 person team, and a whopping 4,950 for a 100 person team. This really illustrates how much the communication overhead takes over everything else as the group size increases.
The article can be found here
The article can be found here
Wednesday, March 16, 2011
The difference between use cases and user stories
User stories say what you want to do. Use cases include the steps involved in the "how" of doing it. So user stories give a higher level pass of the functionality, leaving the details for elsewhere.
Allow me to elaborate. First, use cases. They are defined here as "A description of steps or actions between a user (or "agent") and a software system which lead the user towards something useful."
The key word here is "steps". They are pinning down not only the result, but the high-level steps involved. And they can range from a paragraph to an entire document.
User Stories on the other hand, tend to encapsulate who's using it and what they want. The standard form is usually "As X, I want to do Y", sometimes with a "so that Z" added on. Role, goal, and sometimes benefit. Short and to the point, and like I mentioned with use cases, they leave the how as a later design decision, which I think is why agile development usually uses them. More flexible that way.
Allow me to elaborate. First, use cases. They are defined here as "A description of steps or actions between a user (or "agent") and a software system which lead the user towards something useful."
The key word here is "steps". They are pinning down not only the result, but the high-level steps involved. And they can range from a paragraph to an entire document.
User Stories on the other hand, tend to encapsulate who's using it and what they want. The standard form is usually "As X, I want to do Y", sometimes with a "so that Z" added on. Role, goal, and sometimes benefit. Short and to the point, and like I mentioned with use cases, they leave the how as a later design decision, which I think is why agile development usually uses them. More flexible that way.
Saturday, March 12, 2011
How to fail at agile
So I found a nice little article while researching scrum. It's written as 20 ways to sabotage the adoption of an agile development process, but what I think they're really getting at is traps and pitfalls to avoid. It has sections on the manager, team, and product owner, but since most of us are going to be in the "team" category, I'll focus on summarizing that part. Each point is labeled with the number used in the article, which can be found here
Guideline 6: Continually failing to deliver what you promised.
This would be a big problem in any situation, but with agile it can kill the entire process. The team is expected to deliver a functional "product" that could potentially be shipped at the end of each iteration, and to do that they need to know what the team can commit to. Having a team member keep everyone else guessing like that is just cruel
Guideline 7: Moving work forward to the next iteration casually.
If you're missing your sprint goal, you need to evaluate your estimations of how long those items are supposed to take. Brushing off incomplete goals like that is just asking for trouble
Guideline 8: Not creating cross-functional teams. This one's fairly obvious. If you want to go through the entire design-build-test process for an iteration, you're going to need people who can do all that. Putting all your testers on one team, for example, practically guarantees that you won't be able to have a team put out a complete product for that iteration
Guideline 9: Large groups. As group size grows, group overhead grows with it, and you lose the responsiveness and speed an agile process is supposed to help create
Guideline 6: Continually failing to deliver what you promised.
This would be a big problem in any situation, but with agile it can kill the entire process. The team is expected to deliver a functional "product" that could potentially be shipped at the end of each iteration, and to do that they need to know what the team can commit to. Having a team member keep everyone else guessing like that is just cruel
Guideline 7: Moving work forward to the next iteration casually.
If you're missing your sprint goal, you need to evaluate your estimations of how long those items are supposed to take. Brushing off incomplete goals like that is just asking for trouble
Guideline 8: Not creating cross-functional teams. This one's fairly obvious. If you want to go through the entire design-build-test process for an iteration, you're going to need people who can do all that. Putting all your testers on one team, for example, practically guarantees that you won't be able to have a team put out a complete product for that iteration
Guideline 9: Large groups. As group size grows, group overhead grows with it, and you lose the responsiveness and speed an agile process is supposed to help create
Wednesday, March 9, 2011
Open Source, and what "free" really means
So, as part of my work for my group, I did a bit of looking into open-source business models and profitability of open-source in general, and I found a couple interesting articles
The first, a page from the GNU website concerns selling free software.
The key concept in it is that the idea of "free" in open-source software isn't that you're giving it away at no cost. Sure you can do that, and a lot of people do, but that's not the point. The point is, once you have it, you have it. You are free to do what you want with it, with the restriction that what you do with it is also free in that same sense. This expands the number of people who can contribute to an idea massively. The idea you put out there could be taken in an entirely new direction once someone gets their hands on it. Great for the idea, but how's a company going to make money off of an investment like this? Should we even be considering that?
Well, you can charge for your distrobution, and if people think it's a fair price they'll get it. But it gives them some control. A person who wants to try it can get the full copy from a friend, maybe decide to pay later. A group can get one copy and share it. There's degrees of "pay" built into this idea of distributing, instead of the all-or-nothing you'd see with proprietary software. An interesting thought from the business perspective.
It kind of comes down to selling a service instead of a software, in a lot of ways. There's more of that in another article I found, but that'll be for a later blog post.
Anyways, link
The first, a page from the GNU website concerns selling free software.
The key concept in it is that the idea of "free" in open-source software isn't that you're giving it away at no cost. Sure you can do that, and a lot of people do, but that's not the point. The point is, once you have it, you have it. You are free to do what you want with it, with the restriction that what you do with it is also free in that same sense. This expands the number of people who can contribute to an idea massively. The idea you put out there could be taken in an entirely new direction once someone gets their hands on it. Great for the idea, but how's a company going to make money off of an investment like this? Should we even be considering that?
Well, you can charge for your distrobution, and if people think it's a fair price they'll get it. But it gives them some control. A person who wants to try it can get the full copy from a friend, maybe decide to pay later. A group can get one copy and share it. There's degrees of "pay" built into this idea of distributing, instead of the all-or-nothing you'd see with proprietary software. An interesting thought from the business perspective.
It kind of comes down to selling a service instead of a software, in a lot of ways. There's more of that in another article I found, but that'll be for a later blog post.
Anyways, link
Tuesday, March 8, 2011
Self Evaluation
https://docs.google.com/document/d/1T6tztdFtxaMkXpw93HLdra1u837RNZhURR9bAn6smb4/edit?hl=en&authkey=CKaboTk
Edit: Second Revision
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BwlevxUzk46MZTQzN2ExMWItZDA4Ni00MmU5LWIwOGYtZmVmMmE0ZTJmMDY1&hl=en&authkey=CLnl584L
Edit: Second Revision
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BwlevxUzk46MZTQzN2ExMWItZDA4Ni00MmU5LWIwOGYtZmVmMmE0ZTJmMDY1&hl=en&authkey=CLnl584L
Pressure, comfort, self-sabotage, habits, and learning how to fix problems
Well...This is supposed to be a place I use to show my growth as a programmer and as a software engineer. That, in my mind, includes things that may not be directly related to class content but play a large role in what this class does for me, and what I do in this class.
Up until this point, I've mostly been a coaster. An exceptionally skilled and intelligent coaster to get this far, but still a coaster. Until recently I didn't need to make large efforts. Looking back, I wish I did. So much unused potential. And fixing some of my other issues would have been far easier
You see, one of the things that's gotten into my mind is that venturing out of my comfort zone is...well, bad. Like college. It's a "safe" environment for me. Of course, all good things must come to an end, and so I seek to graduate this spring. This causes an internal conflict, one very difficult for me to recognize, partially because I didn't see the "safe" mindset conciously until I really thought about it. I want to remain, but I also want to leave, to move on and succeed. Initially this semester, the need to remain in a "safe" won out, and I unconsciously sabotaged myself. Now, this is a very interesting bit, because if I were having this though process on a conscious level, I wouldn't have gone the same way. I would have seen, as I know, that failing would not end in me staying in this environment. This needed to be my last semester.
But I didn't think like that, because I didn't even know, consciously, that I was causing myself this problem. And now, I'm faced with another dilema. Give up? Give in to this behavior that caused my problem in the first place, push my schedule back? Or fight it and try to grab victory from the jaws of defeat? I have been told I'm overestimating own abilities. Maybe. But I don't know my abilities, really, because I've never stretched myself. And I think now is the time. One way or another, I need to confront myself and win. Putting that off will hurt me more than anything else possibly can, I think. So no. I will not be giving up. This is about more than just a class now. It's about seizing an opportunity to change my self for the better, once and for all, and how can I give that up?
Anyways, that's my little rambling. More on-topic posts to follow.
Up until this point, I've mostly been a coaster. An exceptionally skilled and intelligent coaster to get this far, but still a coaster. Until recently I didn't need to make large efforts. Looking back, I wish I did. So much unused potential. And fixing some of my other issues would have been far easier
You see, one of the things that's gotten into my mind is that venturing out of my comfort zone is...well, bad. Like college. It's a "safe" environment for me. Of course, all good things must come to an end, and so I seek to graduate this spring. This causes an internal conflict, one very difficult for me to recognize, partially because I didn't see the "safe" mindset conciously until I really thought about it. I want to remain, but I also want to leave, to move on and succeed. Initially this semester, the need to remain in a "safe" won out, and I unconsciously sabotaged myself. Now, this is a very interesting bit, because if I were having this though process on a conscious level, I wouldn't have gone the same way. I would have seen, as I know, that failing would not end in me staying in this environment. This needed to be my last semester.
But I didn't think like that, because I didn't even know, consciously, that I was causing myself this problem. And now, I'm faced with another dilema. Give up? Give in to this behavior that caused my problem in the first place, push my schedule back? Or fight it and try to grab victory from the jaws of defeat? I have been told I'm overestimating own abilities. Maybe. But I don't know my abilities, really, because I've never stretched myself. And I think now is the time. One way or another, I need to confront myself and win. Putting that off will hurt me more than anything else possibly can, I think. So no. I will not be giving up. This is about more than just a class now. It's about seizing an opportunity to change my self for the better, once and for all, and how can I give that up?
Anyways, that's my little rambling. More on-topic posts to follow.
Wednesday, February 23, 2011
My final project picks
No particular order, equal weighting
Thaumatology, by JD
Home automation by AH
Voice-controlled application launcher by GIA
Zombie Earth, by LAG
Thaumatology, by JD
Home automation by AH
Voice-controlled application launcher by GIA
Zombie Earth, by LAG
Wednesday, February 16, 2011
Me and Iphones
After seeing two or three proposed projects for iPhone, I think I'd like to talk about my own experiences with the iPhone.
So, a couple semesters ago, I'm taking this class called mobile app and game development. Work was done entirely on the iphone/ipod touch. Good class overall, but it introduced me to a few things that I simply don't like about the iphone as a development platform.
the first thing, and kind of the big one, is the developer license. It completely defeats the idea of open-source. Good thing? Bad thing? I don't know for sure, but to me it seems like another way for Apple to make money off of people. It's effectively the worst of both worlds, in that you have a restricted development base but not in such a way as to prevent more uninspired...well, let's just say sturgeon's law is in full effect here. Plus, there's less incentive to create "free" games when that translates to the developers having to pay.
the second thing that annoys me is the acceptance process. Now, I have limited firsthand experience, but the way I hear it it's often arbitrary. One particular story I remember from that class is one of the speakers who submitted something, had it rejected, and then submitted the same thing with no changes and it got accepted.
So, a couple semesters ago, I'm taking this class called mobile app and game development. Work was done entirely on the iphone/ipod touch. Good class overall, but it introduced me to a few things that I simply don't like about the iphone as a development platform.
the first thing, and kind of the big one, is the developer license. It completely defeats the idea of open-source. Good thing? Bad thing? I don't know for sure, but to me it seems like another way for Apple to make money off of people. It's effectively the worst of both worlds, in that you have a restricted development base but not in such a way as to prevent more uninspired...well, let's just say sturgeon's law is in full effect here. Plus, there's less incentive to create "free" games when that translates to the developers having to pay.
the second thing that annoys me is the acceptance process. Now, I have limited firsthand experience, but the way I hear it it's often arbitrary. One particular story I remember from that class is one of the speakers who submitted something, had it rejected, and then submitted the same thing with no changes and it got accepted.
Monday, February 14, 2011
Project Proposal and Review
Monday, January 24, 2011
Creativity continues to elude me
Alt Title: The wrong job for the left brain
So today, we were supposed to have a paragraph pitching an idea for our semester project in this class. I came up with one idea that feels too complex, and nothing else...Well, something's better than nothing, I guess, so here's the idea
The project would be to make a game. Specifically, it would be of the "Bullet Hell" sub-genre of top-down/scrolling shooters, the sub-genre also being known as "Curtain Fire". Known for flooding the screen with enemy projectiles and having the player's hitbox being extremely small, They've interested me as a player because of the combination of reflex, pattern recognition, and dexterity to play them, which draws the player in in a way that I haven't seen with any other genre. In a more general sense, I'm interested to see what kind of math and stuff goes into making those projectile patterns.
The games, from what I can tell, aren't well known at all outside of japan. Ikaruga seems to be the best known game, the games from Tohou Project being another well known series.
I just feel like this is too complex for me, especially to get done in a semester. But then, I feel just about anything's too complex. I'm hoping to get a better gauge of how complex it will be and/or come up with other ideas quickly here.
So today, we were supposed to have a paragraph pitching an idea for our semester project in this class. I came up with one idea that feels too complex, and nothing else...Well, something's better than nothing, I guess, so here's the idea
The project would be to make a game. Specifically, it would be of the "Bullet Hell" sub-genre of top-down/scrolling shooters, the sub-genre also being known as "Curtain Fire". Known for flooding the screen with enemy projectiles and having the player's hitbox being extremely small, They've interested me as a player because of the combination of reflex, pattern recognition, and dexterity to play them, which draws the player in in a way that I haven't seen with any other genre. In a more general sense, I'm interested to see what kind of math and stuff goes into making those projectile patterns.
The games, from what I can tell, aren't well known at all outside of japan. Ikaruga seems to be the best known game, the games from Tohou Project being another well known series.
I just feel like this is too complex for me, especially to get done in a semester. But then, I feel just about anything's too complex. I'm hoping to get a better gauge of how complex it will be and/or come up with other ideas quickly here.
This whole blog thing...I don't get it
It's not that I don't understand why. It's that it's...At odds with my nature. I expect that my posts are going to be very dry because of this, but who knows, I may surprise myself.
Subscribe to:
Posts (Atom)