JavaScript and other plans

This post was written 2 years ago.
Fri, 28 Oct 2016
It is very late now, but I suddenly feel this urge to write down those plans I have (carrying on from previous longwinded post which was all about just getting ready to make plans). I just want to make it very brief!

So basically, for let's say the next year, I have these two objectives:
1, Organise at least 5 events/workshops in the coming year, where the unifying principles are:
- The format: Probably 2.5 hours in the evening as a default, but could also be a whole Saturday 9 - 5 or something like that
- The topic: It should in some way help newcomers, and it could be something that you don't necessarily find in every tutorial; for example how to use the unix commandline, dev tools etc. It could also be 'soft' topics like how to organise yourself when you freelance, or how to keep physically and emotionally well; I actually have a list of topics in my head (have had that for a long time). Need to start asking people!

2, Improve full-stack web dev and in particular JavaScript as well as I can. I will measure this by hours, i.e. I will set myself a target of how many hours I'll learn. But I will measure the outcome by other objectives. There will be certain endpoints: a, Can I contribute to open source projects? b, Do I feel comfortable teaching others (formally or informally) and c, Can I build stuff without this being a massive and time-consuming pain? (Relatedly, do I manage to stick to a project and finish it off before I start a new one) I am aware that these goals don't look measurable, still to me they are hard endpoints, because I know how I feel when I've grasped something, and I know how it feels when you need just the right effort for something.
So either I will manage to achieve one or more of these endpoints, or I won't. It's an experiment. If I succeed that would be fab, because then I could really teach and could properly help people - and possibly build cool stuff! . But I am a bit skeptic whether that will be the case. The important thing is that I'll allow myself any possible outcome. As long as I stick to my plan of doing a certain number of hours a week, there will always be an outcome worth talking/writing about. And hopefully there will be some improvement. And I have to say that from when we starte our JS group a bit less than two years ago, my JavaScript has really got so much better!

If I only could always see it like that! Right, I just will from now on. - The 'full stack' aim is also interesting. I sometimes think I need to make a certain switch in my mind if I really want to succeed there. I guess the main thing is to actually believe that I can learn certain things. I took one significant step years ago, which was switching to Linux as my OS and running my own server to host things. I cannot say how glad I am that I did that. But when things become a bit more proper devopsy, that still feels like a bit of a barrier. It is difficult to say what makes sense there, should I not specialise on the front-end and PHP programming? But then, it does all interest me, and people used to do it all, and the way things are set up at work makes it possible to learn at least the basics of the different technologies you need to have a server up and running, keep it secure and sites performing well. I think I (and others) perceive it a bit as a 'guys' thing. I wonder if it's something of a cultural thing where as a woman you have been conditioned to be more careful with everything, not break things ladida. (My fear of breaking things has in the past years gone down quite a bit already though ;) )

Don't know. But as we are on this topic, here's another thing I am going to stop doing. Looking out for, or thinking too much about whether something someone said or ways in which they behaved is sexist (or agist, anti-foreigner? haha, how unusual can I get - and still, I am the urban 'cosmopolitan' middle-class and the people around me are, too, this is so far probably still the one decisive factor to make me compatible, but maybe shouldn't be?). It is such a fine line, and in the end, it is mostly history and people's habits that can lead to situations where you might feel treated differently as a woman. It is not directly anybody's fault. I do think it can become toxic, it depends very much on where you are. But it seems to me that currently, in my personal life, any subtle thing that might happen in this regard, is far outweighed by the opportunities I've been given, the super-flexible work contract, knowing so many great people in Bristol's tech community, being able to learn from others and so on. Besides that, in some regards, when it comes to the gender topic, there are things that have been problematic from my side. This has only gradually become clear to me, and it pains me somewhat, because I fear it has been a bit destructive. But that again, it is a historical thing why I behaved in certain ways, and there is no point in beating myself up about it. Main thing is, I am aware of it now.

Comments

SouthvilleJS JavaScript Workshop

This post was written 5 years ago.
Wed, 11 Sep 2013
Last weekend (7 and 8 September 2013) I attended a workshop run by a JavaScript user group in Bristol called SouthvilleJS - in fact, it was mainly organised by Andrew McGregor, who is one of the organisers of SouthvilleJS. It was the first workshop of its kind as well as being really well organised, and incredibly good value for money (£30 early bird, £40 regular). The ticket price basically just went towards the costs for running this event and I don't think anybody made any money out of it. This is especially amazing considering the line-up and the quality of the sessions.

The location by the harbourside was great, and the lack of internet was not really a problem, with phone tethering and MiFi as options these days. There was also a good mix of people, at different levels of JavaScript skills, and from different backgrounds; next to front-end developers, people from software engineering who were keen to learn more about web technologies. Many of the presenters also stayed on after they had spoken and followed the other sessions. I had not been sure at first whether to attend this event because I am not really a candidate for the user group as I neither live in Southville, nor am I that proficient in JavaScript (when are you a Javascript user?) But I am glad Gicela and Nigel convinced me to take part. Also it turned out that there were a lot more people outside that category, in fact, the workshop might not have run otherwise, I guess!

So here an overview of the presentations:

Node and the Express framework

Jack Franklin kicked off the workshop with a session on Node and the Express web app framework, which is available as a node package. He started with using node's REPL, showing that you can run normal JavaScript and execute files in it. This included a script to set up a server and make content available through it; you wouldn't normally write that yourself, though, as it would be part of a library. One of the nice things about writing JavaScript server side is that you can use all the latest JavaScript functions and don't need to worry about different browser implementations. We also installed a sample Express app, looked at the structure including the package.JSON file to install dependencies, and wrote some code to set up some pages in it. You can find lots of information about JavaScript on Jack's blog JavaScript playground. He has also recently published a book on jQuery.

Modular JS

Next up was Nico Burns. He explained the benefits of writing modular code and the different methods available (AMD, CommonJS, EC Harmony). The presentation made perfect sense to me, and I could see the benefits of this approach especially in large projects. But when it came to restructuring some code that we were given, and make it modular, I struggled a bit. Luckily in the sample code we got, there was a folder with a solution included, and by transforming the original script into multiple files that depended on each other as in the solution, I could understand the structure and how you got there.

Socket.io

Mark Withers introduced socket.io. Web Sockets are one of the new HTML5 APIs, and not fully implemented in all browsers (for IE only from version 10). They enable a persistent connection between client and server as opposed to the HTTP request/response model. This is important for real-time interaction, for example in multiplayer gaming. Using a library like socket.io, you can achieve such a connection across browsers, as it falls back on technologies other than Web Sockets in browsers where those are not available. The practical example involved writing a script that sets up a server (using the Express framework from before), and binds two sockets to two different ports of that server. Next was a client-side script that enables the client to connect to one of the sockets and communicate through it, while receiving the web page through the other socket. In the example, the server sent a message to the client which was then appended as a list element on the page, among other things. The sample code is available on Mark Withers's github.

XMPP-FTW

Socket.io was actually used in the next project, too. Lloyd Watkin presented his library XMPP-FTW, which he wrote to make it easier for developers to enable interaction with XMPP (Extensible Message and Presence Protocol) through a browser. XMPP is an open standard for real-time communication and mostly used in Instant Messaging services, but also in applications like Google Talk (recently replaced by Hangouts) and Facebook chat. An interesting aspect of XMPP is that you can have different 'resources' - which would normally represent different devices - and can set one as priority. Somebody sending a message to your account can either specifiy the resource they want you to receive a message on, or - if they don't specify it - it will go to the one you have set as priority. We got to try out XMPP by connecting to an XMPP system set up by Lloyd on his laptop. We each got an account on that system. Then we wrote some code to connect, and sent little messages to each other, logging them to the recipient's console. We also sent messages to a public messaging wall. Not everybody (including me) did get the code for that right so easily, but we got there in the end! You can find Lloyd's slides online, and here is XMPP-FTW and the pub-sub demo.

Refactoring (and testing)

I won't write much about the last session of the first day, which basically consisted of watching Jack Franklin expertly refactor some jQuery code and explain it as he went along, including the use of unit tests with QUnit, running through PhantomJS. Great stuff. There are posts on his blog on both refactoring and using QUnit.

And after that it was off to "Pub.js" as the agenda stated, but not for me. I think it was better that way, my brain was at that point already quite frazzled without any drinks!

Coffeescript

On Sunday morning, we all turned up again at the boathouse and enjoyed the view onto the Floating Harbour. And then we did Coffeescript. It is a programming language that compiles into Javascript and is much more concise to write. It can be installed as a node package. I quite enjoyed this session, although it will probably be a while before I use Coffeescript, just because I want to get to know Javascript better first. Coffeescript has a lot going for it though, as you can read on this document by Adam Butler who led the session. Adam talked us through the syntax, and the benefits of Coffeescript over JS. We then got some time to try writing something ourselves. Coffeescript works seamlessly with any Javascript libraries, and I tried a little example ivolving jQuery. One of the best ways to learn Coffescript is "backwards" it seems, by using the js2coffee tool. All in all, it was quite rewarding getting some things written in Coffeescript to work, though I did not finish the whole thing. Indepent of Coffeescript, the Dash docsets mentioned by Adam (which you can use with zeal on Linux) were a great discovery.

Angular

There was also one session about a Javascript MVC framework, Angular, presented by Maff Rigby. There is a vast number of frameworks around to build single-page apps, and one conclusion at the end of the session was that the choice you make depends on what specific needs you have for a certain app, but also personal preference. There is not one that is best - they all have different things that they are particularly good at.

Also, there are "opinionated" frameworks that are quite prescriptive in the way you have to structure an app, and those that leave you more freedom. As I understood it, Angular is not very prescriptive. Maff has created a website monitoring app called getTestr with Angular and was showing us how to get started with building an app. At least some of the approach seemed familiar from PHP-based MVC frameworks. I had some stupid difficulties getting things to work though. I say stupid, because they were so obvious in hindsight, and I feel a bit sorry that I bothered both my neighbour and Maff with it. - There was a lot of typing things off the screen in this workshop, and I fell behind with this quite a few times. But I do think it is good practice typing the code yourself. Still I was glad that the speakers also provided the finished examples. (Here you can download Matt's code and presentation).


Leap Motion


 
Playing with Leap Motion More Playing with Leap Motion

In the last session (read a great explanation of what we did on Dave's own website) we got to play with a Leap Motion device. Similar to the Xbox Kinect, it detects shapes and motion through optical sensors. Dave Taylor, who presented this session, had brought a number of these devices and people could work with them in groups of two or three. You can see a schematic and artful representation of your hand on the screen, and the software can also recognize a hand and fingers as well as certain gestures like swipe, circle or a keytap. (It can not always track individual fingers, and they seem to appear and disappear a lot of the time.) One interesting thing is that it also calculates the centre of a sphere that would fit in the palm of your hand.

We could see all the data that the Leap generated in real-time by accessing a file in the browser that displayed the data as JSON. It was quite interesting to see when a gesture was recognized, or seeing the number of hands and fingers change, also finding out the range where the Leap was able to "see". We then got to play a game of Space Invaders where you could move the ship by moving your arm and use your finger to trigger shots. (I love Space Invaders - I really do think it was the first ever computer game I played, on my cousin's Atari.. yes, I'm that old..). We also got to play a multiplayer version (Web Sockets, again!). We then looked at a JavaScript wrapper with the functionality for controlling the ship through movements. We started manipulating the code by making it stop on a certain condition (like a certain gesture). In the process, I learned a useful trick: You can introduce a breakpoint by putting the word "debugger" into a function call. The plan had been to write a better controller class, but it seemed everybody was more keen to play around, and I think we were at that point also lacking a bit in concentration! It was anyway a great session.

Space Invaders

So, that was it. It was an intense and enjoyable two days, and going through the sessions again (I actually looked at the code of all of them where I had it!), I find it has been really useful to me. I wonder what will actually come out of it. I have in any case at least one project where I want to try things out, but I am sure it will benefit my work in general.

Thanks to everyone who made this event possible, especially Andrew McGregor and the speakers!

This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Comments

Dev8D 2012

This post was written 6 years ago.
Thu, 16 Feb 2012

Today I got back from three days in London, where I attended this year's Dev8D. Dev8D is quite a remarkable conference (or more accurately perhaps, a conference, unconference and workshops all in one). It is aimed at developers in Higher Education, but open to anyone interested. It offers a great opportunity to learn new skills, get a feel for what is being discussed and important in certain areas, and meet people with the same interests as you.

I went last year for the first time (it has been running for four years now), and I was very happy to go back. The format of the event seems to have changed slightly every year, but what remains constant is the focus on hands-on-learning, and the informal atmosphere.

As there was so much going on at once, I can only write about a fraction of the sessions from first-hand experience, but for anybody interested in the event I would recommend reading the relevant DevCSI blog posts (there's lots of videos and interviews in there).

message board at dev8d

Some of the sessions that were held were decided on only during the event, through votes from all participants. Out of the fixed events, I had chosen to attend the Python and Javascript sessions. There was also a session on Coffeescript following the Javascript one, but I eventually decided against it as I would rather first know Javascript very well (also I'm not sure about having a language on top of another language; but people seem to have been impressed by it, and I remain curious). Then I learned there was an Arduino workshop on, something that I had missed out on last year. It turned out to be a great experience. We worked in pairs, and I did more of the software part, but mostly followed what my partner was building. And it was nice seeing the results immediately, LEDs flashing, varying potentiometer strength being translated into sounds, and the "grand finale", turning a motor in a certain pattern of slowing down, then picking up speed again. This must be great to do with children.

arduino workshop

There is a lot one could say about the Arduino, and also about the "other guy" that was used for embedded programming in some sessions, a much more powerful microcontroller whith more periphery, including analogue-to-digital translation, though not open-source like the Arduino (or Freeduino, which seems to be what we were using). There were also 3D-printing machines in the room, but I did not attend the session on that unfortunately. Anyway, you can watch a talk about the Arduino workshop by its organiser Gary Bulmer, and here is 3D Printing with Graham Klyne. I see the ST Micro Cortex-M4 STM32F4 (that's the full name of the other microcontroller) had its own workshop, and there's lots of information in the description if you are interested.

The Python and Javascript "Core skills" sessions were also very good. The Python session was billed like this: "It will be presented as a Coding Dojo, with pairs of programmers operating the terminal, being assisted by the rest of the room." That was exactly what we did, with Richard Jones, who ran the session, either dictating what was to be written, or setting up little exercises. I found that this format worked very well, because you could follow along well with people typing, and it was also a good experience being in the "driving seat". I had previously started learning a bit of Python, but it is just so valuable having the particular aspects of a language being pointed out to you by somebody in the know, and then especially in this interactive way. Also, after the session, some of us were shown briefly how to use web.py in a development environment, and we created a mini web application, a calculator taking input from a query string. If you are a Python beginner, check out the Cottage Labs Python Cheat Sheet.

dev8d basecamp

I also got a lot out of the Javascript session. There were two presenters, Juliette Culver and Graham Klyne, who took it in turns presenting a whirlwind tour through the Javascript language, and jQuery respectively. All the examples were available as files, so it was possible to recap afterwards. On the way to the conference I had started my third read of "Javascript the good parts", and it was useful hearing some of the main points being explained again (e.g. what 'this' means in different contexts; don't use a constructor function directly, only in a wrapper). It looks like I'm going to do a lot of Javascript in the coming months, so this is a good starting point.

On the last day I went to a session about ebooks. While I probably won't be needing this soon, I still found it very interesting that creating something in .epub or .mobi format is not actually that difficult. Although I feel that creating something looking nicely formatted and presentable might be a different story. I did not stay till the end of the session and don't know if authoring iBooks got covered in any detail, but it seemed to me that there was not all that great an interest in the class.

There were lots of other things I would have been interested in (there was a session on git for example) and I regret a little that I did not go to any of the panel sessions this year. Maybe next year!


This post was written 6 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Comments

Accidental Javascript programming

This post was written 7 years ago.
Wed, 31 Aug 2011

After doing some programming, starting a book about how to think like a Computer Scientist, and reading Javascript the Good Parts, 1.5 times so far (more iterations will follow), I now have a far better understanding of Javascript than say a year ago. Still, there is much more to learn.

I have had a go at programming something in Javascript though (not jQuery). This was for a w3c course in mobile web development - blog post on that to follow. Javascript had not really been the focus, but rather making things work on desktop and mobile. Anyway, it is a little hangman app - there's simply not enough of them yet ;) . I know I could have found code for this on the web, but I just tried myself. Better not to look at the source code!

I'd quite like to make some changes, allow to choose words from different languages for example. But I think the most important would probably be to improve the user experience of the main interaction in this game: Entering and checking a lettter. Another thing that is bugging me is that the SVG does not work on most phones. There should be a fallback if SVG cannot be displayed.

Anyway, it works reasonably well on a desktop environment - including local storage which means you can close and open the browser and pick up from where you left the game. The list of words is at a sub-teen child's level at the moment, and my children actually like playing it! So here's the little Hangman game.

 

This post was written 7 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Comments