iTechArt Group confirmed the status of an authorized Microsoft Gold Certified software development partner of the next period 2009-2010 years.
Wednesday, June 10, 2009
Tuesday, June 2, 2009
On Cloud 2.0
Today seems like an era of highly cryptic, though actively spun words. In order to be able to maintain valid small talk in the circles bold enough to assume themselves IT savvy, any self-respecting person needs to be aware of the necessary technical vocabulary entailed – the system is relatively closed as of yet, but there’s no limit to perfection, as they say. The must-haves within such a technical inventory include, but are not limited to, (a) Web 2.0, (b) agile, and (c) cloud computing. These are pretty much enough to keep the buzz going, but, as it often happens when things come to buzz, no one is one hundred per cent capable of locating the sound source. The distinguishing characteristic shared by the must-haves is their extreme conceptual looseness – a tendency actively augmented by the blogosphere (to ensure complete unbiasedness, present company will probably have to be included, despite all the best intentions). A randomly selected average netizen will readily expand on the essence of, say, Web 2.0, and the greater overall flexibility it brings with itself in the web, and I must say I’m happy with that, but it somehow seems to me that the flexibility substantially consists in the approaches to defining the term.
On the list of my preferences among the above buzzwords, cloud computing is probably closest to the top, partially due to the term’s rich metaphoric potential. Cloud as a metaphor used to refer to Internet as a whole is now safely trite, but there’s the excitement of finding a silver lining or assigning a numeric value to it (seven might work, given the lovely Windows connotation). Here it should be mentioned that it’s not just me who is seized by the sheer excitement of it (see an Office Offline comic strip, for instance).
The Wikipedia definition for cloud computing positions it as “is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet”. Definitions from elsewhere vary from a version of utility computing to anything that is used out there in the Net, including outsourcing of any kind, come to think of it. Related, yet not identical, concepts include grid computing and autonomic computing, although here the confusion is relatively easily rendered negligible by the underlying narrowness of these counterparts.
Most of the variations emerge when it comes to the cloud versus utility distinction. Even more than that, this leads to the not-so-easy task of classifying the types of services available with cloud computing.
Basically, cloud computing is all about boosting computing capabilities and capacity with little to no upfront investment. This means that a certain company may get its data storage and programming needs satisfied by tapping into cloud computing services. The billing is most commonly used on the amount of resources consumed (hence the utility part of the name). Since the payments can also be made through subscription, some authors feel reluctant completely merging the terms of cloud computing and utility computing, although many a tech guy feels perfectly comfortable with that.
Moving on to the much-dreaded classification, the principle types singled out across various sources are Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), as well as Managed Service Providers (MSPs) and web-based end-user services. Again, it needs to be noted that there’s a great deal of overlapping to these types, so the more or less convenient way of outlining the scope of the services is referring to the major service providers.
By this virtue, what is offered by Amazon.com is known as utility computing, which is providing storage and virtual servers set up, accessed and configured on demand. Thus, Amazon’s Elastic Compute Cloud (EC 2) allow users to acquire additional processing power, and S3 – Simple Storage Service – is the option to meet data storage needs. Similar sets of services are available with IBM and Sun.
Next, Google App Engine and Force.com are associated with Platform-as-a-Service, which essentially implies delivering development environments as a type of service. The major pitfall here is that a developer is not granted full control over the development process. Thus, interoperability and portability may turn out problematic.
Google Apps, as well as Zoho Office, is also an example of web-based end-user services, which offer functionality principally associated with desktop applications only.
Additionally, there are peer-to-peer cloud-based networks, such as Skype and BitTorrent.
On the whole, although the buzz is getting heavier as, in the squeezed circumstances of an economic downturn, companies are seeking to reduce costs by any means available. What is also a significant contributing factor is probably the tendency of surrendering a trend gaining momentum. While bloggers argue their approaches to the cloud computing phenomenon, the nebulous substance is unfolding in its due course, with companies, large and small, trusting their non-critical data to the cloud. It seems that a warning voiced back in 2008 by Richard Stallman, the non-proprietary software advocate (relying on cloud computing “is worse than stupidity; it’s a marketing hype campaign”) will by and large remain on the margin on the computing atmosphere.
Monday, April 6, 2009
Agile Software Development
The term “agile” referring to software development processes is sort of a buzzword, but the intentions of those using the above word may in fact remain quite unclear. By this I mean that agile is sometimes used in its most general sense as “quick; nimble or acute”, whereas in other cases it points to a particular method within the agile development framework (which causes a good deal of confusion, as a matter of fact). Here I would like to look at agile development from what I would call its underlying perspective – agile methodology as a software development philosophy, a set of fundamental features determining the prospects cutting through each and every its elements, all the way from the targeted product to team members and their interaction patterns.
Looking at agile software development as a set of philosophical guidelines seem in fact the only possible way to go since it is prompted by its “umbrella term” nature (which, again, is the culprit of the above confusion). Extreme Programming, Scrum, DSDM, Feature Driven Development , and a number of other things all belong to the agile framework. This is a one-way equation: you switch the parts, and you get a completely warped idea of the whole agile concept. If you have previously dealt with, say, XP and the thing did not seem to work out that well for you, it would be unwise to shift your XP pair work frustration randomly at other things. It is a general-to-specific kind of relation.
While outlining the essence of agile software development, the easiest way to go is defining what is not agile, that is by contrasting it with waterfall development on the one hand and sets of chaotic code-and-fix procedures (or cowboy development, if you will) on the other. (Note: I do in fact realize that negative definitions are logically flawed. What I also realize, however, is that these give you an idea and provide certain valuable directions.) In this line, agile methods turn out to be a middle-of-the-road approach. Agile discounts both the rigidity of the former and the patchiness and anarchy of the latter.
So, what is the agile philosophy about anyway? First of all, agile approaches welcome flexibility and allow for changes at any stage of the development process. With agile development, work is done in shorter iterations (weeks rather than months). The focus is thus shifted off long-term planning, hence greater overall adaptability. Secondly, agile methodologies are highly collaborative, which implies that priority is given to face-to-face communication rather than to formalized written interactions. An agile environment is based on trust, motivation and a considerable degree of self-governance. Thirdly, agile development processes are undertaken in close cooperation with the customer and ensure considerable coherence between both the sides. To wrap it all up in a concise way, it is safe to say that the clue to agile software development processes is working software and its continuous delivery.
My final remark is going to touch upon one more crucial aspect, namely the applicability of agile philosophical maxims to a specific software development environment. Agile approaches need agile team members, which, in its own turn, implies having a mindset of a particular sort.
Looking at agile software development as a set of philosophical guidelines seem in fact the only possible way to go since it is prompted by its “umbrella term” nature (which, again, is the culprit of the above confusion). Extreme Programming, Scrum, DSDM, Feature Driven Development , and a number of other things all belong to the agile framework. This is a one-way equation: you switch the parts, and you get a completely warped idea of the whole agile concept. If you have previously dealt with, say, XP and the thing did not seem to work out that well for you, it would be unwise to shift your XP pair work frustration randomly at other things. It is a general-to-specific kind of relation.
While outlining the essence of agile software development, the easiest way to go is defining what is not agile, that is by contrasting it with waterfall development on the one hand and sets of chaotic code-and-fix procedures (or cowboy development, if you will) on the other. (Note: I do in fact realize that negative definitions are logically flawed. What I also realize, however, is that these give you an idea and provide certain valuable directions.) In this line, agile methods turn out to be a middle-of-the-road approach. Agile discounts both the rigidity of the former and the patchiness and anarchy of the latter.
So, what is the agile philosophy about anyway? First of all, agile approaches welcome flexibility and allow for changes at any stage of the development process. With agile development, work is done in shorter iterations (weeks rather than months). The focus is thus shifted off long-term planning, hence greater overall adaptability. Secondly, agile methodologies are highly collaborative, which implies that priority is given to face-to-face communication rather than to formalized written interactions. An agile environment is based on trust, motivation and a considerable degree of self-governance. Thirdly, agile development processes are undertaken in close cooperation with the customer and ensure considerable coherence between both the sides. To wrap it all up in a concise way, it is safe to say that the clue to agile software development processes is working software and its continuous delivery.
My final remark is going to touch upon one more crucial aspect, namely the applicability of agile philosophical maxims to a specific software development environment. Agile approaches need agile team members, which, in its own turn, implies having a mindset of a particular sort.
Friday, March 20, 2009
Entangled in Terminology
A glimpse into the somewhat enigmatic vocabulary of those creating software is enough to make your head swirl. Words keep popping up now and again – words that seem to ring a bell, but it is when you set the noble, if ambitious, linguistic goal of giving these terms a touch of terminological definiteness that you find yourself in a kind of no man’s land. How is software development different from software engineering, does the word programming serve as an umbrella term for both of those and, last but not least, how does computer science fit into the whole semantic system?
These are the questions that one is likely to find difficult to come to terms with when trying to muster the courage of plunging into the deep waters of IT. And, come to think of it, telling the difference between software development versus software engineering can turn out to be a good springboard for those who are just too obsessed with getting a definition for each and every word, which is exactly my case, those who need to deal with the IT guys and even those planning to get down to creating software (a roundabout term used here for the sake of convenience).
At this point, let me make it clear that in the present piece I’m sharing with you my idea of what might be the catch – an idea based on some observing and thematic reading, but still potentially subjective.
Now, there are a number of layers to investigate. On the one hand, to an average person out there, all the four terms might appear roughly synonymous, which in most cases can be just a piece of knowledge sufficient enough unless the average person needs to actually deal with these things. However, it could be noted here that people are mostly reluctant to expand their world outlooks, hence the fact that the terms programmer and software developer are mostly used interchangeably.
On the other hand, in the academic world, as well among those putting theories into practice, this kind of vagueness is not an option. Firstly, the computer science versus software engineering distinction seems to consist in distinguishing between theory and practice. Secondly, when defining software engineering one has to bear in mind the two components of the word: the engineering part implies that this particular term was at some point coined to emphasize an approach which treats the process of creating software just like any other engineering process, with all the inherent complexity, whereas the software part is there to point to the product’s underlying feature, i.e. its intangibility (in the definition by the Institute of Electrical and Electronics Engineers, software engineering is basically the application of engineering principles to creating software). Yet another aspect of the term can be traced from the programming versus software engineering distinction, i.e. the fact that programming is writing code, period, whereas software engineering incorporates management, coordination and design procedures, along with code-writing. And it is here that we arrive at the most challenging point: where does the borderline between software engineering and software development lie? It seems quite difficult to find any secure grounds to declare these as separate notions. However, the approach suggested by Prof. Gary Pollice in his article at http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html seems sensible enough. It boils down to the following: software development is the process of putting software engineering principles into practice. So here’s what I’ve settled for: software development is a less imposing, real-life word to denote the routine of organizing teamwork, creating specifications, writing code and, if you will, making software production more sustainable by relying on general practices commonly used in other engineering fields.
These are the questions that one is likely to find difficult to come to terms with when trying to muster the courage of plunging into the deep waters of IT. And, come to think of it, telling the difference between software development versus software engineering can turn out to be a good springboard for those who are just too obsessed with getting a definition for each and every word, which is exactly my case, those who need to deal with the IT guys and even those planning to get down to creating software (a roundabout term used here for the sake of convenience).
At this point, let me make it clear that in the present piece I’m sharing with you my idea of what might be the catch – an idea based on some observing and thematic reading, but still potentially subjective.
Now, there are a number of layers to investigate. On the one hand, to an average person out there, all the four terms might appear roughly synonymous, which in most cases can be just a piece of knowledge sufficient enough unless the average person needs to actually deal with these things. However, it could be noted here that people are mostly reluctant to expand their world outlooks, hence the fact that the terms programmer and software developer are mostly used interchangeably.
On the other hand, in the academic world, as well among those putting theories into practice, this kind of vagueness is not an option. Firstly, the computer science versus software engineering distinction seems to consist in distinguishing between theory and practice. Secondly, when defining software engineering one has to bear in mind the two components of the word: the engineering part implies that this particular term was at some point coined to emphasize an approach which treats the process of creating software just like any other engineering process, with all the inherent complexity, whereas the software part is there to point to the product’s underlying feature, i.e. its intangibility (in the definition by the Institute of Electrical and Electronics Engineers, software engineering is basically the application of engineering principles to creating software). Yet another aspect of the term can be traced from the programming versus software engineering distinction, i.e. the fact that programming is writing code, period, whereas software engineering incorporates management, coordination and design procedures, along with code-writing. And it is here that we arrive at the most challenging point: where does the borderline between software engineering and software development lie? It seems quite difficult to find any secure grounds to declare these as separate notions. However, the approach suggested by Prof. Gary Pollice in his article at http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html seems sensible enough. It boils down to the following: software development is the process of putting software engineering principles into practice. So here’s what I’ve settled for: software development is a less imposing, real-life word to denote the routine of organizing teamwork, creating specifications, writing code and, if you will, making software production more sustainable by relying on general practices commonly used in other engineering fields.
Sunday, February 15, 2009
Custom Software Development and Outsourcing
| Do you have too much work and not enough skilled developers? Hire and Manage remote developers from iTechArt as if they were in your office. iTechArt Group is a first class custom software development and software outsourcing company. Our development centers are located in Eastern Europe: Kiev, Ukraine and Minsk, Belarus. We have solid experience bringing software products from concept to release in a variety of development environments. |  |
Technologies list:
.NET/ASP.NET/C#/VB.NET/Atlas SharePoint 2007/WSS 3.0/MOSS 2007 Windows Workflow Foundation/InfoPath .Net Mobile, iPhone, Symbian Silverlight/WPF/WCF | C/C++ (including ANSI C)/WinAPI/Unix Java/J2EE (JDBC, JNI, EJB, JMS, Servlets)/JSP/Struts Web 2.0/Ruby/MySQL/AJAX Flash/Action script/Flex/AIR SEND REQUEST FOR SERVICE |
Subscribe to:
Posts (Atom)
