Programming, SQL Server, SS SLUG

What’s the big deal about SQL Server 2012??

SQL ServerMicrosoft SQL Server 2012 RC0 enables a cloud-ready information platform that will help organizations unlock breakthrough insights across the organization“.

Unless you were living under a rock, you must be aware of the ongoing revolution in the SQL Server world about the much anticipated release of SQL Server 2012 formerly known as SQL Server Denali. The SQL Server 2012 Release Candidate was released last week.

And if your thinking that this is gonna turn out to be another blog post on the performance of the release, you better think twice. I’m not an expert in the development of the release nor do I have a clue of what the hype is all about, but I would like to bring out what I think from an eye of an IT student by connecting the dots and and pieces of what I’ve heard and read.

Just like all software products bring in new versions by improving the flaws of the previous versions and coming up with new adornments to the existing product, the newer version of SQL Server also, successfully maintains the good old tradition. Well, according to the Release Candidate 0 announcement, what can the users enjoy??

  • Greater Availability
  • Blazing fast performance
  • Rapid data exploration
  • Credible, consistent data
  • Optimized productivity

So the buzz is all about these new/ improvised aspects of the product. If you take the track records, you can see the contribution of many tech brains to achieve its current status. But a sure thing is, SQL Server 2012, is not THE Flawless product and we could expect something better than this in the future as well. It’s just another Key milestone of the SQL Server Development!

Advertisements
SSSLUG
Programming, SS SLUG

SS SLUG Kaleidoscope – October 2011 Action


The October SQL Server Sri Lanka User Group meet up consisted of 3 main sessions this time.  Deviating from the conventional SS SLUG meetups, this time the team incorporated a new twist to the agenda to make the evening more interesting. Their first sign of victory was the numbers they brought in for the day.  It was the first time in the history of the SS SLUG a large number of audience gathered.

The agenda for the day was,

The performance graph of the day was similar to a cosine curve.

The first session managed to hit the mark. Dinesh A. spoke of UDFs (User Defined Functions) and also he touched on certain limitations of stored procedures that could be overcome with UDFs as well as instead of writing long lines of queries with stored procedures, how the same thing can be done using few lines of UDFs.

Progressing to the second session, Dinesh P. spoke of the upcoming enhancements made to the BI suite planned by Microsoft and if you’re doing any development for BI, how it would help you to know where you stand compared to the current progress of Microsoft. This session did not raise itself up to as the first session because there was a very small percentage of the crowd who really knew what BI was. Though Dinesh P. managed to give a bird’s eye view into BI before he began his session, as he continued the interest level on the topic dropped a bit low. He spoke of Traditional BI and the emerging trend of Self Service BI. I personally clueless about BI was looking forward for this session, because the topic on the agenda sounded pretty interesting and I assumed that it would give an overview to BI and cover some interesting areas. It was a bit of a disappointment.

Trying to gain momentum, Preethiviraj got into the field with his topic. Another session I was looking forward to. Preethiviraj spoke about what Very Large Databases were, maintaining them and some of the dos and don’ts. Since the first session started behind schedule, Preethiviraj was being hurried to finish his session sooner than the time slot allotted to him. It was a drawback that he had to cut down on his session, because all those who wanted to learn could see that he planned to deliver so much more but couldn’t because they were already behind schedule.

So hoping that next time’s SS SLUG meet up will try to improve on the shortcomings of October’s meetup and try to keep up the enthusiasm and the drive to learn in all the sessions they plan for the day.

Uncategorized

Dev vs QA and QA vs Dev! Competition or Complementation??

The IT World

I began my internship about 11 months back and I initially joined the QA team of the Company. But since I wanted to make a career in the Software Development track, I requested some involvement in certain Development work as well. But consecutively for about six months I solely worked as a Trainee QA Test Analyst. I was allocated to the highest revenue gaining project of the company, which performed updates on particular sites on a daily basis. Unlike the normal projects where the delivery date would be few months later, whereas in this project everyday is a delivery date for us, not less than working in a pizzeria I suppose.

During my QA days, I was the typical QA tester a Developer would encounter 😀 I picked on the silliest mistakes made by the developers, some were genuine while some were illogical bugs…Duh!! And I really could not figure out why the developers always considered the QA sector as their enemies who picked on every single thing they did and reported some illogical bugs which wasted time. Vice versa we QA people also considered the Developers as hard to work with, because it would some times take ages to get their consent on fixing a bug as well as proving that the discovered bug IS in fact a bug! (whew…)

While I was experiencing this tug of war, my request was finally considered and I was given a chance to work as a Developer in the Project that I worked as a QA Test Analyst. This opportunity was an immense eye opener for me as an intern as well as an observer sitting out of the frame.

Following the Cycle, I finished my Development and passed it on for QA. (And YES, if you think I QA’d it myself before sending it for the real QA cycle, you are absolutely CORRECT! I just wanted to make sure that there were no errors when i handed it in 😉 ) And so long for my confidence in zero errors… I got a report back with some errors that I never would have thought existed. But ironically in a developer’s viewpoint I clearly knew that those were not errors caused by the updates that I have made to the site.

For instance if QA reported a design issue, I would play by the cards and the first comment would be “Check if the bug exists in the live site as well”. And next would be, “If it does, let’s inform the leads and if it’s an issue they will let us know if we should fix it or not”. And lastly, “For now, just check the updates I have done, and if you find any issues outside the updates I’ve done, call it for considerations, but not as BUGS! 😉 “. Well these were the very lines I heard every single day when I had to play QA.

No it was not pay back time for me. Though for a second I spoke the same dialogue, I thought from the QA perspective as well. The errors could be certainly illogical, some cannot be solved due to the way it’s coded. But for a QA person, if something looks weird or behaves in an unexpected manner or rather it could be better, that becomes a defect. But when it comes to the hands of the Developer, either the code can’t be changed and it can be ignored or it’s more of a compatibility issue which is not in the hands of the developer.

From what I discovered during my working period was, the reason for the bridge between the understanding of Dev and QA is, that both do not know each others job, in simple terms. If QA got the Dev perspective, I wonder if any bugs would exist for that matter, but still for all, certain bugs that cannot be fixed at all, would be understood in the first place and wouldn’t require time to check those. On the other hand if Dev got a taste of the QA role, again I wonder, if there would be a requirement for a separate group called QA as such. And having said that, it’s better to have a dedicated group of people for that job because at the end of the day, the QA team does report some really good bugs 🙂

Finally for the developers who consider QA as a pain and QA who treat the Developers equally, like it or not, when it comes to the IT arena, both roles complement each other. Else one would be bug prone without the other!

FOSS

Software Liberty/ Freedom

This time of the year in the FOSS community, the buzz is all about “Software Freedom Day!”

So what is “Software Freedom” all about??

This is for those who really don’t get the phrase!

Without getting into much technical jargon, basically what it means is,

Free Software

  • Freedom to access the source code,
  • Freedom to modify the source code,
  • Freedom to use it for whatever you want it to be used (in terms of the technical arena)

And finally,

  • Freedom to distribute your modifications.

What should be highlighted is that it only refers to the “Liberty” to use software.

Liberty to do what you want to do!

So why are they beating the bandwagon of free software??

The key benefit of it is the ability to access and modify the source code. One may ponder on, why would anyone be bothered about the source code without getting the work done? The best answer for this question was given by; Bob Young – Founder of the free software distribution company Red Hat.

Open source gives the user the benefit of control over the technology the user is investing in. This benefit is perfectly obvious to every programmer and system administrator I’ve ever spoken to, but it is sometimes tough for nontechnical journalists to grasp.

The best analogy that illustrates this benefit is with the way we buy cars. Just ask the question, “Would you buy a car with the hood welded shut?” and we all answer an emphatic “No.” So ask the follow-up question, “What do you know about modern internal-combustion engines?” and the answer for most of us is, “Not much.

We demand the ability to open the hood of our cars because it gives us, the consumer, control over the product we’ve bought and takes it away from the vendor. We can take the car back to the dealer; if he does a good job, doesn’t overcharge us and adds the features we need, we may keep taking it back to that dealer. But if he overcharges us, won’t fix the problem we are having or refuses to install that musical horn we always wanted — well, there are 10,000 other car-repair companies that would be happy to have our business.

We all are inquisitive to know how things work. We try to repair stuff or add new elements to the normal equipment we use in our day to day life. So why not be inquisitive when it comes to software?

In a developer’s prospect, accessing the source code would give an opportunity to figure out the problem or enhance the software by adding new features on your own without eagerly awaiting for a day when it will eventually happen. 🙂

And this is just one among many key aspects of Free Software.

17th of September is the Software Freedom Day and this liberty is available for anyone who is willing to get under the hood instead of being on the surface, and make a change!