An Introduction to Artificial Intelligence: Facts and Fallacies

One way or another, we all heard of Artificial Intelligence. It's been there since we were born and it will surely outlive us. It’s a promise of a Utopian future and could be a harbinger of our own demise. It could help us end poverty, disease and pollution or it could see us a threat and decide to take us out. Whatever the future might hold, one thing's certain: Artificial Intelligence is (or will be) the Pyramids of a generation and most likely mankind's greatest creation.

Read more


How to Fix Common Errors When Testing in RSpec

If you are a Software Test Engineer or Quality Control Engineer and you want to automate your API call tests, then you should try RSpec (Ruby's testing framework). I didn’t exactly chose it (the QC team was already using it), but I tend to believe that I would have picked it in the future for my own tests because when it comes to the installation of the program, the process is not that complicated at all.

Actually, let me show you how little you need to do in order to start writing your own tests:

gem install rspec
rspec --init

Yep, that’s all. Now you can automate your tests and run them with the following command:

rspec your_test_suite.rb

I will now show you some common error messages that I've encountered, so that you can avoid them during your work. These errors are caused by very small mistakes, but usually in the rush of delivering quality we skip some things or words.

 

1. syntax error, unexpected keyword_end, expecting end-of-input (SyntaxError)

Let’s take a look at the following examples:

describe 'Test Suite' 
   it 'Validate successful response' do
      response = RestClient.get('www.intelligentbee.com')
      expect(response.code).to eq(200)
   end
end
describe 'Test Suite' do
   it 'Validate successful response' 
      response = RestClient.get('www.intelligentbee.com')
      expect(response.code).to eq(200)
   end
end

So, if you get the above error, you most probably forgot to put a ‘do’ after ‘describe’ or ‘it’ methods.

 

2. syntax error, unexpected end-of-input, expecting keyword_end (SyntaxError)

I will use the same example again:

describe 'Test Suite' do
   it 'Validate successful response' do
      response = RestClient.get('www.intelligentbee.com')
      expect(response.code).to eq(200)
   
end

What is wrong with this? Well, I missed an ‘end’. I’ll take it you can figure out by yourself where it should be placed.

 

3. JSON::ParserError: 757: unexpected token

Take a look:

describe 'Test Suite' do
   it 'Validate successful response' do
      response = RestClient.get('www.intelligentbee.com')
      parsed_response = JSON.parse(response)
      expect(parsed_response['message']).to eq "Some message"
   end
end

Supposedly, sometimes you will get as an answer a JSON and you will want to parse it for better tests. You will get the above error if the answer is not a JSON and the parser can’t find there what it expects.

I hope you will find this short guide useful, I plan to continue writing about common errors that we may encounter while using RSpec.


What Is the Difference between QA and QC/Software Testing

If you work in IT or, at least, had any experience in this area, you definitely know that there are multiple terms to define the testing world. The biggest competitors here are QA (Quality Assurance) and QC (Quality Control) which is basically the same as Software Testing.

Let's see how these are defined:

Quality Assurance (QA) is a part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISO 9000]

Quality Control/Testing is a process that consisting of all the life cycles activities, both static and dynamic, concerned with planning, preparing and evaluating software products and related work products. It tries to determine if they satisfy specified requirements in order to demonstrate that they are fit for purpose and to detect defects. [ISTQB glossary]

Quality Assurance

This is about process oriented and preventive activities. It means that these activities are focused on improving the software development process and that the system will meet its objectives. The QA Engineer is active throughout the product’s lifecycle and communicates with all the people involved in the process, from Project Manager to Software Developer and QC Engineer. The QA analyses and seeks the continuous improvement of both process and product while ensuring all tasks demonstrate appropriate quality and that are finished on time.

Quality Control/Software testing

Well, this is about product orientated activities and it is a corrective process (testing is a process rather than a single activity - there are a series of activities involved). The QC Engineer must find bugs in the system before users do, investigate and report on how well the software performs relative to its expectations and is generally active at the end of a coding cycle.

Conclusions

QA and QC both have to make the software better, however, QA is about process orientated and preventive activities, while QC involves a corrective process and product orientated activities.


Usability Rules and Principles for Websites

We all now that nowadays there are some well known standards when creating a new web application: it must support a big number of users, no errors on loading, it must be responsive and clear. Beside those, every website must have a user-centered design and to have that, here are some rules and principles for usability.

Usability Rules and Principles for Websites

1. 7+-2 Principle
– there must be 7+-2 elements in a navigation bar

2. 2-Second-Rule
– a user shouldn’t wait more than 2 seconds for a response from the server

3. 3-Click-Rule
– if a user cannot access a site functionality or the information in 3 clicks, he will leave the site (this underlines the necessity of having a clean navigation, a logical structure and a simple to follow site hierarchy)

4. Shneiderman’s rules for design
a. Consistency
– consistent sequences of actions should be requested in similar situations
– the same terminology should be used in prompts, menus, help windows
b. Informative feedback
– for every action there should be a feedback system. For minor and frequent actions the response can be modest, and for major and rare actions, the response should be substantial
c. Closure dialogs
– action sequences should be organized in groups with a beginning, middle and an end
d. Easy handling of errors
– the user shouldn’t be allowed to make serious errors
– if an error is produced, the system should be able to detect it and to offer an easy to understand mechanism for treating it
e. The system should permit action canceling

5. Banner-Blindness
– users tend to ignore colored and animated banners, same for other graphic elements
– the focus is moved to the text and hyperlinks

6. Users should be allowed to test a functionality without authentication
– to continue using the functionality, users would be more than happy to fill in a form

7. Registration form
– filling should last about 30 seconds
– if there are too many fields and the user must scroll, horizontal alignment can be a solution
– [Labels] because the forms are vertically oriented (users fill the form from top to bottom), the input label is indicated to be placed above
– [Search box] the ideal width of a search box is 27 characters
– ‘Submit’ button should be either left aligned or centered
– it's better not to name a submit type button “Submit”, but the actual action that is done when the form is sent, for example: 'Create Account', 'Subscribe Now', 'Send Message', 'Register Free'

8. Text
– it's appropriate to use within 3 typefaces in three sizes
– for a natural result you can choose the font size value for the body from the Fibonacci series (16-24-40-64-104)

I hope these rules help you become a better web developer! Good luck :)


How to show the full path in the os x terminal

How to Show the Full Path in the OS X Terminal

Working and constantly switching between multiple projects in the OS X Terminal or iTerm (whatever you prefer) can be hassle since, by default, you cannot see the full path of the directory you're working in. Here's how to change that.

How to show the full path in the os x terminal

But first, in the spirit of full disclosure, I'd like to mention that I only found out how to display the full path after I accidentally destroyed the virtual machine of the wrong project and I had to install the whole damn thing all over again.

 

As you might have noticed, the Terminal only displays the current folder in which you're working so it can be pretty easy to make a mistake when your projects have a similar folder structure or are built with the same framework.

 

This first thing you need to do to address that is to fire up your Terminal and open your .bash_profile file:

sudo nano ~/.bash_profile

Then head over to a new line and add:

PS1="\w$ "

Save and close the file, then restart your Terminal. You should now notice that when you browse through your directories, the path should look something like this:

~/Development/hpm/vagrant$

The \w symbol you noticed stands for "Current working directory, full path (ie: /Users/Admin/Desktop)" while the $ mark followed by a space is simply a separator between the working path and the input area.

How to show the full path in the os x terminal

If you want to make the Terminal look even more awesome, here are some other options you can add to PS1:

\W – Current working directory (ie: Desktop/)

\d – Current date

\t – Current time

\h – Host name

\# – Command number

\u – User name

So for, example, using PS1="\u@\w$ " will output "Sebi@~/Development$ ".

I really hope this small tutorial helped. Have fun!

 


Who Really Invented the Internet?

While some see it as one of the greatest evolutionary steps in the history of mankind, most of us still use it for cat videos and annoying status updates. Nonetheless, the Internet has clearly taken over our lives, being directly present in our homes, our pockets, our workplace and soon enough, even in our brains. But who actually built the damn thing?
Read more


Should You Do Scrum?

"It is not the strongest of the species teams that survives, nor the most intelligent. It is the one that is most adaptable to change."

That should be a good enough reason for all teams out there to adopt Scrum, from wedding planners to construction companies. But that isn't always the case and if you stick around, you're going to find out why.

Read more


Symfony2: Doctrine 2 Entity Listeners

When working on a little more complex application is inevitable that we'll get to the point when we need to trigger an action when something happens somewhere in our application. Quite often is the case that we need to bind our actions to an entity, like for example notify all subscribers to a blog post that the post they are following has changed.

Read more


Symfony2: Forms and Ajax

Making Ajax calls is a trivial task nowadays for any web developer, and I'm sure it's no enigma for all of you how to do it using your favourite Javascript library or framework like jQuery, Angular, Backbone, you name it.

 

But how do we handle these requests in the backend? More specifically, how should we write our controllers to take full advantage of our preferred framework, Symfony 2 in my case, and create a great UX for our consumers (with errors displayed nicely and effortless) and a great feeling for our colleagues with whom we share the code (by using status codes and promises).

Read more


iOS vs. Android - Which One Should You Choose?

 

Six users, six questions. After a (very) long  research about which mobile OS is better between the two, I realized that the simplest way to find that out is by actually talking to people that use them. As you might expect, everyone has its own requirements and tastes, but in the end, one of the two OSs clearly stands out.

Read more