Sunday, September 12, 2010

Java and C# => one in the same?

Many water cooler chat's have inevitably, at one time or another, posed the notion that Java and C# are a different language or strikingly similar in nature.

I really had no stance on the issue, up until about a year ago. One of my colleague's (Tommy), pointed out that if you know C#, then you know Java. At first, take, if you have not programmed in either, you are taken aback. Can they really be similar?

Naaaah. No way. Crazy talk. But really think about it: What is so different?

What's the same about them?
Both are garbage collected runtimes (JVM, CLR)
Disallow multiple inheritance, and allow multiple contracts to be implmented
Syntactically very similiar
Exceptions anyone?
Boxing
inheritance

What's different about them?
C# always run natively, java supports just-in-time compiles (interpreted)
Packages vs Namespaces (packages require a logical directory)
Main v main
c# => partial classes
c# => unmanaged code
editors

The one main difference is that C# is growing at a faster pace at this point. With the addition of linq & lamdba functions, its clear microsoft is rapidly adding features to c#, where as the java process is way more bureaucratic. See the following link => http://jcp.org/en/participation/committee

So, can java programmers progarm in c# and vice versa? Yes.

Saturday, April 26, 2008

Updated: Sample Google App Engine Code

Finished the very minuscule example for entering stocks on a google app engine project. Leave comments if you have questions.

Hope this helps!

Thursday, April 24, 2008

Google App Engine: Scalable web sites for the masses

The first week of April brought the world another gift from Google, or so Google would like us to think. It is called the Google App Engine, an all inclusive hosted web development package without the user needing to buy any hardware what-so-ever. Oh, and it scales a tad, petty detail. The engine uses Python on the app server, and a datastore, that is transactional but not relational. Seems kind of odd, but the datastore stores and retrieve entities, or python classes, and the data model that google provides in python, called GQL, allows you to create and manipulate these entities that have been created in your program. If you have seen an ORM (Object Relational Mapper), then you would be more familiar with google's query language in python. For more information check out the following links:

For more info on:
The data store
Python on the app engine

It all sounds great up until you ask how much does this all cost to the app developers? Nothing this good grows on trees, and that is definitely the case as shown below here:

Fixed Quotas

Quota Limit
Apps per Developer 3
Storage per App 500MB

Quota Limit
Emails per Day 2,000
Bandwidth In per Day 10,000 MB
Bandwidth Out per Day 10,000 MB
CPU Megacycles per Day 200,000,000
HTTP Requests per Day 650,000
Datastore API Calls per Day 2,500,000
URLFetch API Calls per Day 160,000

Not too bad for a small little site! The only gripe I seem to have involves getting your data out if you want to leave Google. How do you do this?! Well, at the moment you can't, and that means your completely locked in! The pricing structure goes up...too bad! Your screwed. But, it is Beta and I am willing to give them the benefit of the doubt...with dummy applications.

We've heard all about the overview, and the pricing, but what about the freakin code?! You develop these applications with SDK Google provides.


class Stock(db.Model):
ticker = db.StringProperty()
name = db.StringProperty()
price = db.FloatProperty()

class MainPage(webapp.RequestHandler):
def get(self):
stocks = Stock.all().order('-name')

if users.get_current_user():
url = users.create_logout_url(self.request.uri)
url_linktext = 'Logout'
else:
url = users.create_login_url(self.request.uri)
url_linktext = 'Login'

template_values = {
'stocks': stocks,
'url': url,
'url_linktext': url_linktext,
}
path = os.path.join(os.path.dirname(__file__), 'index.html')
self.response.out.write(template.render(path, template_values))

class StockTransaction(webapp.RequestHandler):
def post(self):
stock = Stock()
stock.ticker = self.request.get('ticker')
stock.name = self.request.get('companyname')
stock.price = float(self.request.get('price'))
stock.put()
self.redirect('/')

def main():
application = webapp.WSGIApplication(
[('/', MainPage),
('/transaction', StockTransaction)],
debug=True)
wsgiref.handlers.CGIHandler().run(application)

if __name__ == "__main__":
main()



<table>
<thead>
<tr>
<td>Ticker</td>
<td>Name</td>
<td>Price</td>
</tr>
</thead>
<tbody>
{% for stock in stocks %}
<tr>
<td>{{stock.ticker}}</td>
<td>{{stock.name}}</td>
<td>{{stock.price}}</td>
</tr>
{% endfor %}
</tbody>
</table>
















{{ url_linktext }}

Tuesday, January 15, 2008

Mac World 08' - MacBook Air


Yesterday, Mac World 08' kicked off in spectacular glory. It was phenomenal as usual. Steve Jobs just has a way about him, that instills with you with the utmost confidence that Apple will never let you down. Every MacWorld I remember has lived up to some sort of hype going all the way back to the iPod. If you haven't already seen it, you can check it out the keynote here. He had four agendas to share with the public.
  1. Reveiew of 07' / Lepoard
  2. Iphone/Ipod
  3. Apple TV
  4. Air
The most interesting topic was the MacBook Air. It is the slimmest notebook in the history of laptops weighing in 3.0 lbs, and less then an inch thick. It can literally fit in an office envelope. You would think at this point, what components of the computer did they compromise in order to make this notebook so small? Nothing. They didn't compromise anything. They have a 13.3" screen, 2GB RAM, 80 GB hard disk, full size keyboard, and a full size display. What about the processor? It's a 60% smaller core 2 duo! Intel really pulled a rabbit out of a hat with this remarkable work of engineering. In fact, the whole electronics of the MacBook is as long as a pencil and as wide as a crayon. Just incredibly small.

Good work Apple, you keep finding ways to entice me into buying your products.

Agile Development Demystified

If your a software developer, you have undoubtedly come across this term at one point in your career. You may have heard such things as, this development methodology will help organize software development into more lightweight, manageable development modules. This, in theory, will increase the time to market for the product that you have just spent a lot of developer coin on. Is it reasonable to want to spend your developer coin efficiently? Of course it is, especially if you can get to the market with your product in a cyber world that punishes the late comer. Well, I would like to spend some time with you today giving you my own take on what agile development is, from being immersed in it for the past 40 days, and through one book.

I have always heard the term agile development, but never had a clear vision of what it was. These methods were explained in synonymous terms in my software engineering course. It was described merely as an iterative process. That really doesn't explain what exactly agile development is. So what is it? In simple terms, agile development is a process where you do many of the little things to aid in the efficiency of developing software programs rapidly.

Kind of a vague definition. Let me give you some concepts that would be considered agile.
  1. You work closely with customers
  2. Clear, presentable and maintainable goals
  3. Development happens in iterations or cycles
  4. Collaborate with members of your team to solve problems
  5. Ability to respond quickly to ever changing requirements and customer demands
  6. Accurate estimates of software completion
Now, that is not all what agile is. That is just the beginning; a taste of what an agile project feels like. Agile development requires a highly cohesive group of people, committed to coming up with schedules, collaborating with one another for problems and code reviews, and hitting deadlines set for each iteration that has been planned. If you don't have a highly cohesive atmosphere, you can forget this methodology.

Here is a small example, that will make what I described more concrete. Let's say we have just started an agile project an agile project to create the next greatest social network ever. It's called, for those of you wondering, Social B-Free, for the hippy inside of you. Let us assume there are 10 developers on the team with 3 people in QA. If you were lucky to get that many people on your project, your good and have a great future in sales. Now that we have the people, the CEO has now set the development iterations for two weeks, since we are a fresh startup, and have a killer idea that will revolutionize the social networking industry. The only catch is, we need to get it out now, and grab some market share before someone else implements our brilliant idea. So, how do we accomplish this quickly and efficiently?

We accomplish this by setting meetings and taking a hard look at what can be accomplished in those two weeks. We define all of the features we think can be crammed into that two week time line and we stick to it. From those features, you break them down into even smaller, manageable tasks and denote them on a, list, spreadsheet, word document or some sort of wiki to keep track of it. As the CEO, he has graciously volunteered to keep track of the development lists and holds these meetings every week, keeping track of the progress of the application every day through emails, im, or whatever medium the group has decided to use. By doing this everyday for a month or two, you will become a much better predictor at what will and will not be released during those iterations. By being a better predictor, you can then start to have confidence in releasing features on a date that you specified, you could hit at the beginning, middle or the end of the iteration. By making frequent releases on time, your customers will be confident that progress is continuously being made on the application they are using. It won't become stale to them.

You may ask, what happens when we don't hit those two weeks with all the features included on the list? If that is the case, the CEO has the ability to push features to the next iteration if the CEO does not think they will be hit. There is a lot of power, and flexibility in our methodology. And by keeping at this methodology, we are getting smarter at prognosticating what the team can accomplish during those two weeks.

It's important during every iteration, to make sure everyone in the group understands the problem they chose or were assigned, every day. If there is a problem of understanding, then that problem needs attention as soon as possible. This is where having a good group dynamic comes in to play, where ideas and questions are not ridiculed and people are not criticized. Rather, ideas are encouraged, new ways of attacking problems is the norm, and finished iterations are rewarded (pizza party?). The group becomes a haven for creativity as well as ingenuity. And all while this happens, you are continuously developing solutions on the current iteration with blazing speed. The group becomes a gigantic knowledge base where no one is left behind and new people are up to speed in hours, not days.

The opposite happens when negativity enters the foray. When this happens it is inevitable that your innovation, the very heart of creating software will perish. Why? The people that are receiving negative comments are now hesitant to volunteer any of their ideas, whether it be for fear of ridicule or reprimand. The cause of not volunteering those ideas does not matter. What matters is they have now stopped giving you ideas! What if they had a good idea?! Being negative has just stifled it, along with your innovation, which is priceless to your business. Especially our really cool, hip, new social networking startup Social B-Free. We don't want this puppy to go under.

I hope I have conveyed a small portion of what agile is. I will continue the trials and tribulations of Social B-Free, very soon!