28 September 2015, by Zoe Cunningham
I’ve been volunteering with Ghanaian charity Ashanti Development for nearly 7 years. Ashanti Development was started when Martha Boadu came to England from Ghana. Her plan was to save money that she earned for working so that she could personally pay to install clean water into her home village of Gyetiase. She teamed up with her neighbour in London, Penny David and they quickly found that this was achievable. Luckily lots of people believe in this as a goal and so they raised the money and put in a piped water system.
Following on from this they continued to received grants and expanded their work to include building latrines, hygiene training, health and micro-credit and economic development. They also expanded geographically to help the villages surrounding Gyetiase. In 2013 Softwire sponsored the local village of Bonkron and we continue to provide support to them. (We just built a kindergarten.)
This year Penny asked me to become a Trustee of the charity. As a trustee, I attend board meetings and help make the executive decisions of the charity, to make sure that it is fulfilling its objectives and delivering as well as it possibly can. Like being a director of a private company, I am now (jointly with the other directors) responsible for ensuring that the charity is complying with the law and completing any necessary paperwork.
It’s early days for me, but I’m delighted to be able to contribute more to the charity, using skills that I have developed in my business career. As a trustee I do of course continue with all my other activities to support the charity – Softwire are going on a trip to visit Bonkron for the first time in January 2016.
20 September 2015, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
As a busy manager, you want your technical team to deliver the work you need so that you can hit your targets. You don’t need to know how they do it, or the finer points of their problems. Or do you?
I don’t need to explain why being a cog in a giant machine over which you have no control is demotivating. The opposite of this is having a manager who is interested in what you are doing and why you are doing it.
You’ll never be able to build up the level of expertise that your team has, but you can use that to your advantage. There is nothing more flattering than being asked to explain what you do by someone who respects how useful it is and acknowledges that they couldn’t do it themselves. And of course, building up your knowledge can only increase your ability to make decisions and communicate them upwards.
If you’re not from a technical background, taking an interest at more than a superficial level will open up a new world to you. If your senior developer is off, you may be able to point junior developers at the right resources. You can have a constructive discussion around issues that arise, rather than an argumentative one. You can do this, not because you know better, but because you’ve learnt enough to know how to listen to people who do know better.
The other key way to gain respect from your technical team is to make it clear how you can be useful to them. The best way to help is by using your own expertise: management. If you respect and value their space of execution, and show them how it would be useful for them to align it with yours, you’ll have an unbreakable bond.
As a developer, I was close to the bottom of the pack. As a result, I started developing along different lines in the support team, where I got more credit for being nice to people. This led into management – and suddenly, the techies whose ability to construct elegant, performant functions had dwarfed my own were suddenly reporting to me.
It was a little bit of a shock to everyone concerned. Like most new managers, I was keen and enthusiastic. I didn’t stop to think how this might look to people who were already doing the job better than I could.
I soon realised that only by making the effort to make myself useful would I come to be regarded as such. So I started to focus on how I could actually be helpful. I took away troublesome admin tasks. I helped open up new opportunities that the developers were trying to move into. I asked the question ‘How can I be of help?’ And I didn’t stop until I got an answer.
18 September 2015, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
I’m a great fan of continuous improvement, and feedback is the lifeblood of continuous improvement. Whenever you undertake something, you should be thinking carefully about what could have been done better; this will provide you with some great improvements without any outside help. But there will be a whole class of things that you could be doing better that you won’t be able to spot. In order to become the best manager that you can be you need to find out this information, and act on it.
To get to the position that you’re in now, you will have already had to learn how to act on feedback. At the bottom of an organisation, feedback is usually relatively easy to come by: if you do something wrong, you’ll find out about it; if you upset your boss, they’ll tell you. You’ll also be keen to ask for feedback, and your manager will be happy to give you it.
Things change a little when you are the one in charge. It’s no longer obvious to others that you want people to feedback to you frequently and honestly, even if you state as much in departmental presentations. It can also be easy when you are rushed and busy to respond to feedback curtly or peremptorily, even if you do find it useful and later go on to act on it. Or you may have an emotional reaction to feedback, especially if you do feel deep-down that you have done something badly. Add that to the fact that giving useful, honest feedback is actually really hard, and you might find that people fear giving you honest feedback in case they upset you.
I have previously blogged the following rules for accepting feedback.
- Whatever the feedback is, immediately say ‘thank you for the feedback’. This shows them that you appreciate their taking the time to help you, and will mean you get more feedback in the future.
- Before disagreeing (or agreeing!) with the feedback, take 15 minutes, or however long you need, to absorb the information… or calm down.
- Only then think about whether you agree with the feedback or not, and what you plan to do about it.
- Feed back to the feedback giver on how useful their feedback was! Remember, this is something that they probably didn’t find easy, so take the time to let them know how they did and provide any constructive comments you have to help them get better.
It’s not necessarily the case that all feedback you receive will be equally useful – if you let people know which bits were most helpful and which were less so, it will help them to practise continuous improvement on their feedback giving.
15 September 2015, by David Simons
This blog posts aims to compare how well the two work: we don’t want to fall in to the trap of suggesting that they are competing with each other as they both do different things. However, as two libraries that make front-end development easier through attributes, it’s rare you’ll use both and so you’ll often reach a time on a project where you have to make a decision between two.
Setting the Framework Up
Setting KnockoutJS up is as easy as you’d like it to be – you can pull the source file into your project by downloading it, linking to their CDN or using package management tools such as Bower. It works nicely with all major dependency tools such as RequireJS, or can be included globally in your project. All you need to do to get it working is call ko.applyBindings in one place. It works nicely with all of your code, and can be added at any stage in the project as it plays nicely with other libraries.
AngularJS is a bit more of a tricky beast – building a project around it from the beginning is not much more effort than KnockoutJS. There’s slightly more boilerplate at an early stage to deal with modularisation, but these costs are mostly compensated by not requiring the set-up of, say, RequireJS.
Adding AngularJS to an existing project, however, is significantly harder. Because of the opinionated idioms that come from the use of AngularJS, it’s often hard to make it integrate seamlessly with other code you’ve already written. We’ve used AngularJS with other module loaders, for example, but the cost of maintaining that has been far higher than expected.
Conclusion: On greenfield projects, both libraries perform well. KnockoutJS is easier to add incrementally to an existing project.
A minor point, but if you have to support Internet Explorer, then you may have a harder time with AngularJS that has a small number of outstanding issues on all IE builds; and no support for IE versions 8 and under. KnockoutJS goes all the way back to IE6.
Conclusion: If IE6 or 7 support is important, AngularJS cannot be used.
We have to be careful about comparing raw statistics of two libraries of differing sizes. In terms of Google Search trends, AngularJS is over 12 times as popular, and exponentially rising. Angular is the second most installed bower package, whilst KnockoutJS doesn’t make the top 100. The trends certainly suggest that AngularJS has more staying power.
AngularJS’s modular nature makes it a natural fit for community support as people can add directives, modules and services that can be easily pulled in and integrated with your code. This means that if you’re requirements are common, then you can use a large number of off-the-shelf libraries.
KnockoutJS does allow you to write bespoke additions by creating your own bindings, or extending the knockout object itself in an easy and well-documented manner. Although there are some KnockoutJS libraries to add features such as Pager.js for routing, there are definitely fewer. At least a few times I’ve thought “Surely someone’s done this already” when writing features with KnockoutJS.
Conclusion: AngularJS is much more popular, and has more community libraries.
Ease of Learning
The documentation and online tutorial for KnockoutJS are some of the best I’ve seen. Knockout is so simple and light-weight that when new developers see it, they’ve always taken to it immediately and are able to contribute to development teams very quickly.
AngularJS is a much bigger beast. Their documentation is, necessarily, much more heavyweight and bulky to reflect the larger amount of things that people have to learn. Almost everyone who has worked long enough with AngularJS is now happy with how it works and can contribute speedily, but it often takes longer to reach the same depth of understanding.
Conclusion: KnockoutJS has simplicity and brilliant documentation on its side; the larger AngularJS can’t compete.
KnockoutJS is unopinionated about tests – it’s a much smaller library so we wouldn’t expect anything else. If KnockoutJS is used with some modularisation frameworks (which we always strongly recommend!) then good discipline, such as encapsulating all low-level DOM manipulation, makes unit testing no harder than with any other library.
Conclusion: Both libraries are testable, though AngularJS was written with this very much in mind, making set-up marginally easier and more documented.
So, which is better…?
We’ve found in projects at Softwire uses for both frameworks.
We typically favour KnockoutJS on projects that have less need for the larger, more opinionated AngularJS. This could be because there is less complex interactions between the user and the data; or because the project simply runs for a shorter time. For legacy projects, it allows us to use it minimally only where we need to, preventing a large initial investment of effort. A lot of developers here love KnockoutJS and many use it on their own pet projects because of its light-weight approach.
We have, however, used AngularJS successfully on a number of projects. We’ve found that the ramp-up time is slightly higher, as it takes control of more aspects of the code base. However, if there is sufficient complexity or on a project, or the code base is larger, the initial set-up and learning costs on a project quickly repay itself and it becomes our framework of choice on large projects with potentially complex user interactions.
We are, as we are with all technologies that we use, constantly examining the ecosystem for new and maturing options outside of these! For those interested in seeing more frameworks in action, TodoMVC is a great website that codes the same site using multiple different libraries.
11 September 2015, by Chris Arnott
Outlook is both a blessing and a curse. A recent post by the BBC suggests that receiving too many emails can damage one’s productivity. The extremist response here would be to ban internal e-mails, but realistically that’s probably not a very achievable solution. So is there anything you can do to help you wade through the information that’s being piped into your inbox? We think so, and the answer is outlook filters. (more…)
8 September 2015, by David Simons
4 September 2015, by Emily Fox
As I look at the calendar, I realise it’s a month to the day since I started my internship here at Softwire. Four short weeks later and I’m working on a software project using technologies I’d not really even touched before arriving here, and day by day as foreign web technologies start to make sense I grow a new found appreciation of the depth of what a job in software can lead you to.
The first few weeks
At the start of my time here we had two weeks of training. We started off with some exercises learning C# to help us get used to the language.
Having come from a Java background this was not too steep a learning curve for me, although my code was riddled with the artefacts of someone who’s clearly finding it difficult to leave Java habits behind (who declares all their variables with ‘var’ anyway?!), and like someone learning a foreign language, the statements were sometimes written in a rather interesting mix of the two…
Once those habits had been sufficiently suppressed, we were to learn the art of interacting with external APIs. We signed up to the TfL developer portal and were before long querying their site to find the movements of the local London buses. Unfortunately, after a few initial queries all working rather well, the TfL API went down and we were left with a day of coding for an API that was no longer functional… less than ideal, but we coped! By the end of the day we had a simple program working which would take your postcode, find your nearest two bus stops and give you the times of the next five buses for each.
A real project
It is usual for interns to work on an internal project during their time at Softwire, but we were lucky enough to be offered the chance to work on an actual commercial project, which was exciting! I was to be part of the front end team, and my first tasks were creating some social media widgets for the websites we would be making. By doing this I got to put into practice using the aforementioned web technologies, as well as getting to grips with the software (Umbraco) we are extending for our purposes.
Having eight of us relative newbies working on a single project has its own problems; our Git repository is looking a little reminiscent of tangled spaghetti and a smooth working process has yet to be fully developed, but I like to believe we’re making good progress. One of the things I have enjoyed most so far is the fact that when you have a good number of people working on a single project, although you only contribute a relatively small part, you can see advancements fairly quickly with lots being achieved in a relatively short time.
You can also split responsibilities to allow each person to have their area of expertise on the project. For example, while I was writing my widgets for the front end I had to rely on calls to the API that the back end team had written using technologies such as SQL and C#. So although I had a weaker knowledge of the how the database functioned on a micro level, I could still use what they had written and vice versa.
Currently I am working on some more widgets which will be part of the integral functionality of the software, and we are hoping to have a simple prototype version working by the end of the week, so I’m looking forward to that. I am only half way through my time here at Softwire, but I think the most important thing I have learned so far is a bit of what it’s really like to work in the industry and I have to say it doesn’t disappoint!
4 September 2015, by Tim Perry
Sometime it’s nice to give back. There’s the lovely warm feeling of Doing Good, but then we’ve found it’s also a great way to improve your knowledge of your tools, train your development skills outside of normal project work and give ourselves (and everybody else) better tools to use in future. It feels good to be able to look back at the improvements you’ve made to, and to reflect on work we’ve been doing recently.
That’s what I want to do with this post: highlight some of the great contributions Softwire people have made back to the open-source community so far this year, and talk about options for finding things to help out with and getting more involved (both for us, and to encourage any of you who feel keen after reading this!).
Recent open-source contributions we’re proud of:
- Matthew Richards – Lots of hard work to update Hyprlinkr to Web API 2.2 and .NET 4.5, to let you use Web API 2’s [Route] attribute
- Dean Merchant, Olly Levett, Conor O’Neill, Jake Mckenna and Charles Rea – Releasing an open-source Pool Ladder app
- Rupert Wood – Updating Postmark-Java to use the new Maven HTTPS URL
- Peter Harley – Finding and filing an Akka bug to get incorrect error messages fixed
- Jamie Humphries – Updating Github’s default .gitignore files to ignore NCrunch debris, releasing SignalR.HubStrong to add strong typing to SignalR client-server calls, and fixing search in Hexo
- Michael Kearns – Updating the Lodash docs for _.merge to clarify some ambiguity
- Tim Perry (me!) – Improving the Lodash TypeScript type definitions, adding Docker deployment to Staytus, fixing aggregation query issues in Sequelize, publishing some Docker images, and lots more development on Loglevel.
- Chris Arnott – Adding custom inspection support to scala-scapegoat-plugin
- Richard Bradley – A huge set of fixes and improvements to scala–scapegoat–plugin, scalariform, akka and sbt-scapegoat
- Dan Corder – Releasing an open-source LongArithmetic exercise generator, and continued maintenance and development of Archiverify
- Ciprian Florescu – Updating Cocoon to transform it into a jQuery widget
- Iain Monro – Filings bugs to get issues in Docker and Akka fixed.
- Mike McLean – Continued work and maintenance of his EnumStringValues NuGet package, including a 2.0 release! (With some review help from Harry Cummings)
- Harry Cummings – Releasing Hypermeter, a Node command-line HTTP response time metrics tool
Want to get involved?
Inspired by any of the above, and interested in trying your hand at a bit of open-source contribution yourself? We’ve put together a list of useful ways we’ve found to find and dig into interesting projects:
Help write Firefox’s Dev Tools
Mostly just needs JS/HTML/CSS skills. firefox-dev.tools has a list of bugs for total beginners to get started with, including a filter to find ‘mentored’ bugs, where there’s somebody assigned to help whoever picks the bug up first get set up and going. wiki.mozilla.org/DevTools/GetInvolved has more details.
Interested in helping out with other Mozilla open-source projects (Firefox OS, Rust, Servo, Firefox itself)? Take a look through whatcanidoformozilla.org.
Subscribe to interesting projects on CodeTriage
Help write better documentation
DocsDoctor will send you bits of documentation from projects you subscribe to; take a look through them, thing about whether they could be improved or clarified, and put in a quick patch to make everything more understandable for everybody.
For the more hardcore, you can also sign up to get totally sent undocumented methods and classes, and try and put together some useful notes on what they’re for and how to use them.
Make the tools you use day to day better for everybody
What libraries are you using at the moment? Do they work perfectly? Anything in the API that’s confusing, any poor documentation, or weird behaviour you have to work around? Send them a quick bug on Github, or have a look at fixing it yourself, and make your life (and everybody else’s) easier forevermore.
Come work for Softwire
We love this stuff, and we’re hiring.
1 September 2015, by David Simons
In Softwire, we’ve used AngularJS and KnockoutJS on a variety of projects, and have found that this makes web development a lot easier and a lot more pleasant! With this series of blog posts, I’m hoping to share what we’ve found out about these, and other, data-binding libraries along the way by looking at:
- What groups all these libraries together?
- How do these libraries work?
- Which library is the “best” one?