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.
Life, Code and the Pursuit of Happiness
Sunday, September 12, 2010
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!
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:
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.
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()
{{ url_linktext }}
<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>
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.
- Reveiew of 07' / Lepoard
- Iphone/Ipod
- Apple TV
- Air
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.
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!
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.
- You work closely with customers
- Clear, presentable and maintainable goals
- Development happens in iterations or cycles
- Collaborate with members of your team to solve problems
- Ability to respond quickly to ever changing requirements and customer demands
- Accurate estimates of software completion
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!
Subscribe to:
Posts (Atom)