Barriers to Successful End-User Programming

In my research and my personal life, I have come to know numerous people that our research community might call end-user programmers. Some of them are scientists, some are artists, others are educators and other types of professionals. One thing that all of these people have in common is that their goals are entirely unrelated to producing code. In some cases, programming may be a necessary part of accomplishing their goals, such as a physicist writing a simulation in C or an interaction designer creating an interactive prototype. In other cases, programming may simply be the more efficient alternative to manually solving a problem: one might find duplicate entries in an address book by visual search or by writing a short Perl script

Static Analysis of Android Secure Application Development Process with FindSecurityBugs

Mobile devices have been growing more and more powerful in recent decades, evolving from a simple device for SMS messages and phone calls to a smart device that can install third party apps. People are becoming more heavily reliant on their mobile devices. Due to this increase in usage, security threats to mobile applications are also growing explosively. Mobile app flaws and security defects can provide opportunities for hackers to break into them and access sensitive information. Defensive coding needs to be an integral part of coding practices to improve the security of our code. We need to consider data protection earlier, to verify security early in the development lifecycle, rather than fixing the security holes after malicious attacks and data leaks take place. Early elimination of known security vulnerabilities will help us increase the security of our software, reduce the vulnerabilities in the programs, and mitigate the consequences and damage caused by potential malicious attacks. However, many software developer professionals lack the necessary security knowledge and skills at the development stage, and secure mobile software development is not yet well represented in most schools\u27 computing curriculum. In this paper, we present a static security analysis approach with the FindSecurityBugs plugin for Android secure mobile software development based on OWASP mobile security recommendations to promote secure mobile software development education and meet the emerging industrial and educational needs

Automatically Fixing Syntax Errors Using the Levenshtein Distance

Abstract:To ensure high quality software, much emphasis is laid on software testing. While a number of techniques and tools already exist to identify and locate syntax errors, it is still the duty of programmers to manually fix each of these uncovered syntax errors. In this paper we propose an approach to automate the task of fixing syntax errors by using existing compilers and the levenshtein distance between the identified bug and the possible fixes. The levenshtein distance is a measure of the similarity between two strings. A prototype, called ASBF, has also been built and a number of tests carried out which show that the technique works well in most cases. ASBF is able to automatically fix syntax errors in any erroneous source file and can also process several erroneous files in a source folder. The tests carried out also show that the technique can also be applied to multiple programming languages. Currently ASBF can automatically fix software bugs in the Java and the Python programming languages. The tool also has auto-learning capabilities where it can automatically learn from corrections made manually by a user. It can thereafter couple this learning process with the levenshtein distance to improve its software bugcorrection capabilities.Keywords: Automatically fixing syntax errors, bug fixing, auto-learn, levenshtein distance, Java, Python(Article history: Received 16 September 2016 and accepted 9 December 2016

Debugging: The Key to Unlocking the Mind of a Novice Programmer?

Novice programmers must master two skills to show lasting success: writing code and, when that fails, the ability to debug it. Instructors spend much time teaching the details of writing code but debugging gets significantly less attention. But what if teaching debugging could implicitly teach other aspects of coding better than teaching a language teaching debugging? This paper explores a new theoretical framework, the Theory of Applied Mind for Programming (TAMP), which merges dual process theory with Jerome Bruner’s theory of representations to model the mind of a programmer. TAMP looks to provide greater explanatory power in why novices struggle and suggest pedagogy to bridge gaps in learning. This paper will provide an example of this by reinterpreting debugging literature using TAMP as a theoretical guide. Incorporating new view theoretical viewpoints from old studies suggests a “debugging-first” pedagogy can supplement existing methods of teaching programming and perhaps fill some of the mental gaps TAMP suggests hamper novice programmers

Crossed Wires: Investigating the Problems of End-User Developers in a Physical Computing Task

Considerable research has focused on the problems that end users face when programming software, in order to help them overcome their difficulties, but there is little research into the problems that arise in physical computing when end users construct circuits and program them. In an empirical study, we observed end-user developers as they connected a temperature sensor to an Arduino microcontroller and visualized its readings using LEDs. We investigated how many problems participants encountered, the problem locations, and whether they were overcome. We show that most fatal faults were due to incorrect circuit construction, and that often problems were wrongly diagnosed as program bugs. Whereas there are development environments that help end users create and debug software, there is currently little analogous support for physical computing tasks. Our work is a first step towards building appropriate tools that support end-user developers in overcoming obstacles when constructing physical computing artifacts

Ajonaikaiset virheet ja niiden tunnistaminen

Käsittelen tässä tutkielmassa tietokoneohjelmien ajonaikaisia virhetiloja. Vikatilassa ohjelma voi kaatua, jonkin toiminnon suoritus voi keskeytyä tai ohjelma voi tuottaa vääriä tuloksia. Vikatilat voivat johtua fyysisen ympäristön aiheuttamista tietokoneen sisäisen tilan odottamattomista muutoksista tai ohjelmoijan tekemistä virheistä. Perehdyn tutkielmassani pääasiassa erilaisiin tietokoneohjelmien ajonaikaisiin virhetiloihin ja niiden tunnistamiseen kirjallisuuden avulla. Pohdin myös sitä, miksi ohjelmoija saattaa tehdä virheitä ja miten virhe ohjelmoijan kirjoittamassa ohjelmakoodissa voi aiheuttaa vikatilan ohjelmaa ajettaessa. Tutkielman tutkimuskysymys on: Minkälaisia ohjelman tai ohjelmiston ajonaikaisia virheitä on mahdollista esiintyä ja miten ne on mahdollista tunnistaa? Kuvaan tutkielmassa erityisen virhealttiita ohjelmistorakenteita ja asioita, jotka johtavat ohjelmoijan tekemään virheitä ohjelmakoodin kirjoittamisessa. Yksi karkea virheiden luokittelu on jako muistivirheisiin, rinnakkaisuusvirheisiin ja semanttisiin virheisiin. Muistivirheet ja rinnakkaisuusvirheet ovat myös semanttisia virheitä, mutta semanttisilla virheillä tarkoitetaan usein sellaisia virheitä, joita ei voida luokitella tarkemmin. Rinnakkaisuusvirheet rajoittuvat ohjelmiin, jotka hyödyntävät rinnakkaisuutta. Bittien kääntyminen on yksi esimerkki laitteistotason virhetilanteesta. Miksi bitit laitteen muistissa saattavat kääntyä nollasta ykköseksi tai päinvastoin ja miten se voi vaikuttaa ohjelman toimintaan? Laitteen ja ohjelmiston (esimerkiksi satelliitti) yhdistelmää suunniteltaessa täytyy huomioida bittien kääntymiset. Ajonaikaisten virhetilojen tunnistaminen on tärkeää. Kuvaan miten bittien kääntymisiä voidaan tunnistaa ja korjata sekä laitteistollisesti että ohjelmallisesti. Kuvaan myös lyhyesti kahta menetelmää, joilla voidaan todeta ohjelman toimivan väärin. Ensimmäinen näistä menetelmistä perustuu ohjelman ajoitusten seurantaan. Toinen perustuu poikkeamiin ohjelman suorituspolussa. Tutkielmani tulos on katsaus tapahtumaketjuun siitä, miten virheitä syntyy ohjelmiin ja millaisia ajonaikaisia virheitä voi ilmetä sekä miten ohjelman virheellinen toiminta voidaan tunnistaa. Bittien kääntyminen on edelleen ongelma, joka täytyy pitää mielessä erityisesti laitteita suunnitellessa. Muistivirheiden määrä yleensä vähenee ohjelman kehityksen edetessä ja suurempi osa virheistä on semanttisia virheitä. Rinnakkaisuusvirheet riippuvat siitä, onko ohjelmassa käytetty rinnakkaisuutta. Ne ovat erityisen vaikeita tunnistaa ja korjata, koska niitä on usein vaikea toistaa

Does Unit-Tested Code Crash? A Case Study of Eclipse

Context: Software development projects increasingly adopt unit testing as a way to identify and correct program faults early in the construction process. Code that is unit tested should therefore have fewer failures associated with it. Objective: Compare the number of field failures arising in unit tested code against those arising in code that has not been unit tested. Method: We retrieved 2,083,979 crash incident reports associated with the Eclipse integrated development environment project, and processed them to obtain a set of 126,026 unique program failure stack traces associated with a specific popular release. We then run the JaCoCo code test coverage analysis on the same release, obtaining results on the line, instruction, and branch-level coverage of 216,392 methods. We also extracted from the source code the classes that are linked to a corresponding test class so as to limit test code coverage results to 1,267 classes with actual tests. Finally, we correlated unit tests with failures at the level of 9,523 failing tested methods. Results: Unit-tested code does not appear to be associated with fewer failures. Conclusion: Unit testing on its own may not be a sufficient method for preventing program failures.Comment: 5 pages, 6 figures, 17 reference