In the future, data analytics are going to be invested in a lot heavier due to the shear amount of information certain companies will need to collect and maintain. This issue is one that not only needs to be solved, but it also needs to have it’s issues prefaced before progression – which is what is hindering it.

This article from centraljersey.com talks about the rapid speeds needed to meet deadlines for “high demand” analytical solutions. It goes into how certain markets are investing in analytical technologies in order to predict the future thus being able to optimally market services. However, the article states that three main factors are causing a great hindrance to this push. These factors are security, privacy, and error prone databases. Not only do these kinds of methods take time, they also need to be secure. Not only to protect mass amounts of data, but to operate as efficiently as possible.

Upon reading this article, what interested me is that North-America accounts for the largest market share due to the growing numbers of “players” in the region. Per the article, a lot of this is being invested for cloud-based solutions. What I found interesting, however, is that this company (Market Research Future), provides research to their clients. They have many dedicated teams devoted to specific fields, which is why they can craft their research very carefully. What I find useful about this posting is that it shows just how important the future of data analytics and organization can be. With the future of data collection, there will need to be more, optimized solutions to handle and control these types of research data.

The content of this posting confirms my beliefs on how cloud computing and cloud based data analysis will continue to grow and evolve rapidly over the coming years. With more and more companies migrating to cloud based systems, not only for internal means, but for client needs as well, we will see a great push in optimized data sorting and faster data transfer. Expansion in cloud computing and web-based services will become the main staple of future products such as this.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

“Hacker, Hack Thyself”

Stack Overflow co-founder and author of the blog “Coding Horror” Jeff Atwood writes in this post about his experience trying to secure his open source project “Discourse” from security threats. Atwood discusses the hashing algorithms they use to protect their database and users’ data, as well as the strategies they used to test the strength of their cyber security and password policies.

To test their designs, the developers attempted to hack into their own software, and track the estimated time it takes their systems to crack passwords with varying lengths. They did this by creating various passwords on the servers, starting from the most simple allowable strings of digits, increasing the length of the passwords, and moving on to more complex passwords with words and numbers combined. What they found was the passwords that combined case-sensitive letters and digits would take up to three years to crack.

By cracking the hash functions of these passwords, and recording the amount of time it took to do so, the developers had meaningful data that informed them of their software’s resilience to security threats, and presumably would have a significant effect on their password policies and development of future hash algorithms, if needed.

I found Atwood’s post both interesting and informative. It was interesting to see the strategies the developers used to protect their database from what Atwood describes as a “A brute force try-every-single-letter-and-number attack”. Still I was surprised to see how much of a difference in time it took them to crack the simple passwords compared to the complex ones.

On the technical side of things, I scratched the surface on a lot of important concepts in this post that I would love to learn more about. For instance, Atwood goes into some detail about the proper complexity and number of iterations that should go into a solid hash function. That type of knowledge is extremely valuable in developing secure programs.

Atwood concludes his post expressing a better understanding of specifically what type of attacks his software is strong and vulnerable against. I definitely agree with Atwood’s proactive philosophy about cyber security, and I believe that kind of reasoning is instrumental to being a successful software developer.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

As I take a step towards my journey in Software C.D.A. I am told that for my first task I must find a blog related to the class topic. The blog I chose was “The Solid Principles of Object Oriented Design” by Joseph Smith. I chose this blog cause it’s about one of the Object Orientated Design Principle. A topic that was supposed to be cover on the first day of class, but was not covered since we ran out of time. This blog was short simple and direct to the topic, hence why I chose it. The content in the blog is about the S.O.L.I.D. Principle of Object Oriented Design. I will give a summary of what the blog was about and what it explained from my point f view and understanding. It goes as follows:

There is about five Object Oriented Design Principles known as SOLID. This SOLID principle is used by Software Developers to help them successfully develop applications that are clearly workable.

SOLID stands for the following:

S)  SRP – Single Responsibility Principle.

• This means that a class only really need one duty, and only one motive to change.

O)  OCP – Open Closed Principle

• This means that a class needs to be open for extension, and closed for any changes.

L)  LSP – Lisko Substitution Principle

• This means that the child class must allow the parent class to be interchangeable with it. Meaning the child class can inherit from the parent class by utilizing a copy of all or sum of its objects and change what’s within the object to what relates to the child class.

I)  ISP – Interface Segregation Principle

• This means a class is not required to use any methods it does not need. This is possible through Interface Segregation by taking the larger interface and splitting them into smaller ones, all the way until a class implementation of the interface. Once that happens it only will have relevant methods.

D)  DIP – Dependency Inversion Principle

• This means that high-level of modules are independent of low-level of modules, but both are dependent of abstraction. However, abstraction is not dependent on details and vice versa.

Then the blog finish by saying it will continue with more in-depth information of these principles the next few weeks. It also suggests we go on Wikipedia if we seek more information or detail on the subject so, I did. Well the reason mainly being that I was unclear on the Dependency Inversion Principle. I had to go on Wikipedia to see how it’s explained on that site and if I could understand the concept better. Okay, let’s just say I did so the definition I place on the DIP section was obtained from Wikipedia and not the blog itself. Now, other than that part of the blog everything else was understandable and explained the principle. I found the link to the Wikipedia page useful. I like how the Arthur only focused on the SOLID principle because it’s a pretty big subject and very easy to get lost and confused. This blog has taken me on the right directing to understanding one of the subjects related to the class Software Construction, Design, and Architecture (CS-343). I honestly liked this blog and it made me realized I know some of the topic since it has been covered in past CS classes. I am eager to learn more as it will help perfect my skills.

This has been YessyMer in the World Of Computer Science, thank you for your time until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.