Saturday, 15 November 2014

Learning to play a song before learning the chords....

Recently, I volunteered at my first 'hackathon' for girls from schools around the region, learning to build their own mobile apps. Currently my research has not led me into mobile application development, so I thought it would be a good exercise to learn about these and also volunteer and encourage more young females to take up software engineering in the future.

The hackathon in actual went very well, very excited students, who very clearly extremely creative and willing to learn more about the new HTML tags while building their applications. They used tools such as X-ray goggles (web page analysis), Thimble (online compiling), Ratchet (for mobile app), codeacademy HTML and Byethost (hosting the apps). Cool tools and new innovative solutions were being developed.

I did a mini survey, on asking them what they want to do when they grew up? Surprisingly, none of them said they wanted to do computing. It was either History, Art or any other social sciences, but all wanted to learn how technology works. They did say these kind of events could raise their awareness and willingness to take on computing in the future. Fingers crossed.

However, from an engineering point of view, I found how hackathons run in general, could be damaging to computing in general in the future. The manner in which the students were taught how to code, was to first give them an example and show them how it works by compiling it. And then the students were told to go experiment and start updating the code for their own applications. There was no stage of requirements gathering, state machine explanations, algorithmic explanations or even a design phase!

"Here is an example, now change various lines of the code (by copying and pasting) and go create your own."

It reminded me of my days of learning to play the guitar where it was drilled into me that I needed to perfect the chords before going on to the songs. Now, although I do understand that you only have two days in a hackathon, to produce working apps. But wonder whether actually being part of a hackathon, has completely destroyed the basics of software development in these kids. All of them went away thinking, "O this is easy, its just copying and pasting."

Although I appreciate the efforts, STEM is trying to do to attract more females into computing. I fear whether this approach would be the correct one which (1) does not destroy their basics in software engineering (2) undermine the 4 years of studying of a software engineering degree in the future (3) has a reaction, on some student when they start thinking that they actually do not need a degree in software engineering or development.

Tuesday, 21 October 2014

Concern for software engineering as a discipline

I find myself having this conversation again and again with 'other' engineers on whether software engineering can be described as an engineering discipline.
For some reason people think if they can right code that makes them into software engineers automatically, is that a good argument?
In the UK, it seems you would rather call yourself a computer scientist rather than a software engineer.

Being trained in the proper discipline route of becoming one, in my opinion software engineering is very similar to other engineering disciplines, the only issue is that we tend to be more connected to our clients, thank others, as our products are deployed in many platforms. Not only do you have to 'just write code' but also go through all the processes of correctly building it, testing and deploying it on various kinds of hardware, which each can be a problem in its own right.

I worry that the new era of having anyone develop their own mobile apps or software, even if they write their own algorithms for parsing data, will eventually cost the discipline the true mechanisms of building good software for the various kinds of problems faced in day-to-day lives.

For those unconvinced engineers, I ask would you call a technician who can repair your car an engineer?


Monday, 20 October 2014

Intellectual property now being affected by cloud computing

This can be an argument for opensource software being distributed through clouds.

http://bits.blogs.nytimes.com/2014/10/11/cloud-computing-is-forcing-a-rethink-of-intellectual-property/?_php=true&_type=blogs&_php=true&_type=blogs&smid=li-share&_r=1&


Thursday, 11 September 2014

Testing out this toolkit http://portswigger.net/burp/.
I am trying to figure out if it uses simulation to walk through the web services. Would be useful if there was a video to explain this.

Friday, 22 August 2014

Interesting article:

Productivity or Sexism in Computer Science research fields?


https://www.insidehighered.com/news/2014/08/18/study-raises-questions-about-why-women-are-less-likely-men-earn-tenure-research

Thursday, 10 July 2014

http://www.smartsciencecareer.com/strategies-to-block-female-scientists-with-gender-policy/
(authors: Sven Hendrix and Virginie Bito)

5 successful strategies to block the career of female scientists with gender policy

After several decades of fighting for equal rights for women in academia there are new rules and guidelines on the European and national level to support the career of women in
science. One strategy is to aim for an equal distribution of genders in all academic settings. Surprisingly, these important strategies for gender equality have some unwanted side-effects which impair specifically the careers of young female scientists.

“You are selected because you are the best candidate – and we also need a woman in the commission”

Universities and other scientific institutions have to adapt to the European and national guidelines on gender equality. In principle, this means that in all boards, commissions and selection committees there should be a balance of male and female members to break through the male dominance in science. Interestingly, this may lead to a devaluation of female staff members because their competence and expertise for a specific function gets overshadowed by the strong argument that there has to be a certain number of female members in the commission anyway. They want to be chosen because they are qualified and the best candidate and not because they are a woman. Finally, this may even lead to doubts about the scientific qualities of the female researcher.

“Congratulations, you are member of another 7 committees”

When starting as a young staff member female scientists may be flattered by being invited to numerous boards, commissions and selection committees. However, they quickly realize that all these academic activities cost a huge amount of time. These young female staff members spend a considerable amount of time in meetings which are mostly dominated by male senior scientists. In contrast, their young male colleagues are free to work hard on their careers e. g. by investing in excellent research. In the long run, academic functions add some bonus to their CV but there is considerable debate whether this time shouldn’t be better invested in science than in endless meetings.

“The dean really wants you to be in this commission”

Since the University has to follow the European and national regulations,  there is a strong peer pressure to accept these ‘nominations’. As a result, the female researchers lose their  freedom to say “no” and to choose carefully the functions they want for their careers and in which they feel competent.

“Where have you been during the last 7 selection procedures?”

As a result, the young female staff members may tend to participate only formally in many boards, commissions and selection committees. Thus, they are “officially” members to let the university follow gender equality rules but they are not physically present. This has two negative side-effects: Firstly, gender equality is not taken seriously anymore and may start to exist only on paper (and the meetings are still dominated by senior male decision makers). Secondly, their absence in these meetings will be commented on and documented regularly and may be interpreted as a lack of motivation and interest in these functions.

“The chairman is a man, do you want to be the vice-chairwoman and write the meeting report?”

Another time consuming side-effect of the new regulations is that every important function filled with a man must be balanced by a female “number 2”. The upside is that women grow easily into higher policy functions because in many political settings there is a tradition to select vice chairs as the successor of the current chair. The downside is that these (vice) chair functions are normally associated with a lot of additional administrative and organizational work such as preparing and leading meetings, writing meeting reports and communicating with the administration.

“As a woman would you please give a talk on work/life balance in science ?”

Finally, there is a well-intended tendency to address the burning questions of work/life balance in science by selecting young female researchers as “representatives of a new generation” who know better how to handle work and family life. This supports the stereotype that primarily women are responsible for family and children. From our experience it is rather difficult to motivate male researchers to give a presentation about work/life balance if this is not their research subject.
The current generation of young female researchers will probably break through the patterns of the “glass ceiling” and of the male dominance in boards, commissions and selection committees. It may be advantageous for the current generation of young female scientists to go for a gradual implementation of this policy – especially in domains where the policy is still incompletely implemented and where the number of female scientists is low. Simple rules such as “at least one woman in every commission” may be a better start than implementing a 30% or 50% rule.
In conclusion, there are surprisingly negative side-effects of the well-intended gender equality policies which should be debated and handled.

Wednesday, 2 July 2014

For those wondering what software engineering is as compared to computer science...

No they are not the same thing! Found this link the best to explain the difference:
https://users.csc.calpoly.edu/~djanzen/secsdiff.html

1. Computer Science covers the core concepts and technologies involved with how to make a computer do something. Learning to program a computer by writing software is essential, and computer programming is used in most computer science courses. You will learn details about how computers and networks work, but with an emphasis on how software and programming languages work. You will learn how to make them do very sophisticated things (e.g. graphics, robotics, databases, operating systems). You will also learn about the theory behind how and why computers and software work. In your senior project, you will tackle a problem at the frontier of computer science. You may be building a new system, discovering better ways to design software, or developing new algorithms for projects in entirely different fields; it is up to you. Past student projects include: video games, computer modeling and animation tools, and a Linux driver for the Wii remote.

2. Computer Engineering teaches you how to design systems that include both computer hardware and software. You will take classes on how computer hardware works and how to build a computer. You will take software classes with an emphasis on hardware-related software such as device drivers and operating systems. Computer engineering courses are taught by faculty from both the computer science and the electrical engineering departments. Working computer engineers design computers and the basic software that runs them, including both personal computers and the "embedded" computer systems that run cars, aircraft, videogames, etc.

3. Software Engineering focuses on how to design and build software in teams. You will take many of the same courses as you would in computer science, but you will take additional courses that teach you about topics like requirements engineering, software architecture, software testing, and software deployment. You will learn about working with people (communication, management, working with non-technical customers), processes for developing software, and how to measure and analyze the software product and the software process. The software engineering major requires that you take a three course (nine-month long) sequence called the software engineering capstone. The capstone courses are centered around a large project for an outside customer. In recent years we have built web applications for Intuit (makers of Quicken, QuickBooks, and TurboTax) and Amgen (a bio-engineering/pharmaceutical company). Students work in teams of four or five people to elicit and develop requirements for the system, design an architecture, build prototypes, implement the system, then deploy and maintain the system.

Tuesday, 1 July 2014

I found the Cloud playground an extremely useful tool to get acquainted with python scripts and app development. Good work here: https://cloud-playground.appspot.com/playground/
The effect of technology on young minds

Having grown up in a time when mobile phones were just started to become common, I cannot relate to kids having ipads, phones etc as one of their necessary toys. Watching babies playing ipad games, makes me wonder whether this use of technology is good for their development skills at such a tender age.

I am not convinced that this is the next big step for a technology led society. Maybe we need to compartmentalise technology and its role in our lives.