LUG Community Blogs

Andy Smith: Currently not possible

Planet HantsLUG - Sun, 12/10/2014 - 11:18

On Thursday 9th, after weeks of low-level frustration at having to press “close” on every login, I sent a complaint to Barclays asking them to stop asking me on every single login to switch to paperless statements with a dialog box that has only two options:

This morning they replied:

Please be advised that it is currently not possible for us to remove the switch to paperless statements advert.

So, uh, I suppose if you’re a web developer who thinks that it’s acceptable to ask a question on every login and not supply any means for the user to say, “stop asking me this question”, there is still a job for you in the banking industry. No one there will at any point tell you that this is awful user experience. They will probably just tell you, “good job”, from their jacuzzi full of cash that they got from charging people £5.80 a month to have a bank account, of which £0.30 is for posting a bank statement.

Meanwhile, on another part of their site, I attempt to tell them to send me letters by email not post, but the web site does not allow me to because it thinks I do not have an email address set. Even though the same screen shows my set email address which has been set for years.

After light mocking on Twitter they asked me to try using a different browser, before completely misunderstanding what I was talking about, at which point I gave up.

Categories: LUG Community Blogs

Andy Smith: Diversity at OggCamp comment

Planet HantsLUG - Fri, 10/10/2014 - 22:57

There’s an interesting post about diversity at a tech conference. It is itself a response to a number of tweets by an attendee, so you should read both those things, and probably all of the other comments first.

I’ve now tried twice to add a comment to this article, but each time my comment disappears into the ether. Mark tells me that he is not seeing the comments, i.e. they are not being held for moderation, so I just assume some bit of tech somewhere is failing. Yes, I do get the captcha challenge thing and do complete it successfully. Blog comment systems are awful aren’t they?

So anyway, here’s the most recent version of the comment I tried to add:

I originally wrote this comment on the evening of the 6th, but the blog appears to have eaten it, and I no longer have a copy of it so I’ll have to try to re-type it from memory. Also since then I note a number of other comments which are highly opposed to what I wrote, so you’ll have to take my word for it that this is genuine comment and not an attempt to cause strife.

I do not believe that OggCamp specifically has a problem and I agree with much of what Mark has written, particularly that the unconference format is not in fact used to excuse lack of diversity (though it can be, and doubtless will be, by someone). I do believe that OggCamp has tried quite hard to be welcoming to all, and in many ways has succeeded. There seems to be a slightly larger percentage of female attendees at OggCamp compared to other tech conferences I have been to. I feel strongly that there is a larger percentage of female speakers at OggCamp.

I do however believe the widespread observation that tech conferences and tech in general do have a problem with attracting people who aren’t white males. I do believe that any group organising a conference are obligated to try to fix this, which means that the organisers of OggCamp are.

Stating that there is no such problem and that everyone is welcome is not going to fix it. Clearly there is a problem here, there’s people reporting that there’s a problem and they don’t think you’re doing all that you could do to be welcoming. There’s a word for telling people who say they’re subject to an unwelcoming environment that they in fact are wrong about how they feel, and I’d really like for this not to go there.

However I do not think that many of the things that Mark has proposed will actually make any difference, as well-intentioned as they are. To help improve matters I think that OggCamp should do some things that Mark (and many others in these comments, apparently) will not like.

I am in favour of positive reinforcement / affirmative action / speaker quotas / whatever you want to refer to it as, as part of a diversity statement. Like, aspirational. To be regarded as a sort of “could do better” if it wasn’t achieved. I believe it has shown to be effective.

My first suggestion is to have some sort of diversity goal, perhaps one like, “ideally at least one largest-stage slot per day will be taken by a person who is not a white male”. If we assume one largest stage, two slots each on morning and afternoon, that’s four per day so that’s aiming for 25% main stage representation of speakers who aren’t white males. I believe the gender split alone (before we consider race or other marginalised attributes) in the tech industry is something like 80/20 so this doesn’t sound outrageous.

My second suggestion—and I feel this is possibly more important than the first—is to get more diversity in the group of people selecting the invited speakers. I think a bunch of white males (like myself) sitting about pontificating about diversity isn’t very much better than not doing anything at all. Put those decisions into the hands of the demographic we are trying to encourage.

So, I suggest asking zenaynay to speak at the next OggCamp, and I suggest asking zenaynay if they know any other people who aren’t white males who would like to speak at a future OggCamp.

I do not think that merely marketing OggCamp in more places will fix much. People that aren’t white males tend to be put off from speaking at events like OggCamp and the only way to change their minds is to directly contact them. More diverse speakers will lead to more diverse attendees.

In the same vein, there’s the code of conduct issue. We tend to believe that we are all really nice guys doing the best we can; we would never offend or upset anyone, we would never exclude anyone. The thing is, people who aren’t like us have a very different experience of the world. So just saying that we’re not like that isn’t really enough. Codes of conduct for conferences are a good idea for this reason. Many people who are not white males will not attend a conference that doesn’t have one, because they feel like there is no commitment there and they’re not welcome (or in many cases, safe).

Ashe Dryden compiled a useful page of tips for increasing diversity at tech conferences. If there is genuine desire to do this then I think you have to come up with a great counter-argument as to why it isn’t worth trying the things that Ashe Dryden has said have worked for others. Codes of conduct and diversity goals are in there. As is personally inviting speakers.

“We don’t have time to run a full CFP process” seems like one of the stronger counter-arguments to all of this, to which I think there are two answers:

  1. Don’t bother then; nothing changes.
  2. Try to find volunteers to do it for you; something may change.

Shanley Kane wrote a great collection of essays called Your Startup is Broken. Of course this is about startups (and a US-centric slant, too) not conferences, but it is a great read nontheless and touches upon all the sorts of issues that are relevant here. I really recommend it. It’s only $10.

Finally, I feel that many of the commentors are being a little too defensive. Try to take it as an indictment of the tech sector, not an indictment of OggCamp, and try to use it as feedback to improve things.

Categories: LUG Community Blogs

Wayne Stallwood (DrJeep): Hosting Update2

Planet ALUG - Thu, 09/10/2014 - 22:31
Well after a year the SD card on the Raspberry Pi has failed, I noticed /var was unhappy when I tried to apply the recent Bash updates. Attempts at repair only made things worse and I suspect there is some physical issue. I had minimised writes with logs in tmpfs and the frequently updated weather site sat in tmpfs too..logging to remote systems etc. So not quite sure what happened. Of course this is all very inconvenient when your kit lives in another country, so at some point I guess I will have to build a new SD card and ship it out...for now we are back on Amazon EC2...yay for the elastic cloud \o/
Categories: LUG Community Blogs

Chris Lamb: London—Paris—London 2014

Planet ALUG - Thu, 09/10/2014 - 18:19

I've wanted to ride to Paris for a few months now but was put off by the hassle of taking a bicycle on the Eurostar, as well having a somewhat philosophical and aesthetic objection to taking a bike on a train in the first place. After all, if one already is possession of a mode of transport...

My itinerary was straightforward:

Friday 12h00
London → Newhaven
Friday 23h00
Newhaven → Dieppe (ferry)
Saturday 04h00
Dieppe → Paris
Saturday 23h00
(Sleep)
Sunday 07h00
Paris → Dieppe
Sunday 18h00
Dieppe → Newhaven (ferry)
Sunday 21h00
Newhaven → Peacehaven
Sunday 23h00
(Sleep)
Monday 07h00
Peacehaven → London
Packing list
  • Ferry ticket (unnecessary in the end)
  • Passport
  • Credit card
  • USB A male → mini A male (charges phone, battery pack & front light)
  • USB A male → mini B male (for charging or connecting to Edge 800)
  • USB mini A male → OTG A female (for Edge 800 uploads via phone)
  • Waterproof pocket
  • Sleeping mask for ferry (probably unnecessary)
  • Battery pack

Not pictured:

  • Castelli Gabba Windstopper short-sleeve jersey
  • Castelli Velocissimo bib shorts
  • Castelli Nanoflex arm warmers
  • Castelli Squadra rain jacket
  • Garmin Edge 800
  • Phone
  • Front light: Lezyne Macro Drive
  • Rear lights: Knog Gekko (on bike), Knog Frog (on helmet)
  • Inner tubes (X2), Lezyne multitool, tire levers, hand pump

Day 1: London → Newhaven

Tower Bridge.

Many attempt to go from Tower Bridge → Eiffel Tower (or Marble Arch → Arc de Triomphe) in less than 24 hours. This would have been quite easy if I had left a couple of hours later.

Fanny's Farm Shop, Merstham, Surrey.

Plumpton, East Sussex.

West Pier, Newhaven.

Leaving Newhaven on the 23h00 ferry.


Day 2: Dieppe → Paris

Beauvoir-en-Lyons, Haute-Normandie.

Sérifontaine, Picardie.

La tour Eiffel, Paris.

Champ de Mars, Paris.

Pont de Grenelle, Paris.


Day 3: Paris → Dieppe

Cormeilles-en-Vexin, Île-de-France.

Gisors, Haute-Normandie.

Paris-Brest, Gisors, Haute-Normandie.

Wikipedia: This pastry was created in 1910 to commemorate the Paris–Brest bicycle race begun in 1891. Its circular shape is representative of a wheel. It became popular with riders on the Paris–Brest cycle race, partly because of its energizing high caloric value, and is now found in pâtisseries all over France.

Gournay-en-Bray, Haute-Normandie.

Début de l'Avenue Verte, Forges-les-Eaux, Haute-Normandie.

Mesnières-en-Bray, Haute-Normandie.

Dieppe, Haute-Normandie.

«La Mancha».


Day 4: Peacehaven → London

Peacehaven, East Sussex.

Highbrook, West Sussex.

London weather.


Summary
Distance
588.17 km
Pedal turns
~105,795

My only non-obvious tips would be to buy a disposable blanket in the Newhaven Co-Op to help you sleep on the ferry. In addition, as the food on the ferry is good enough you only need to get to the terminal one hour before departure, avoiding time on your feet in unpicturesque Newhaven.

In terms of equipment, I would bring another light for the 4AM start on «L'Avenue Verte» if only as a backup and I would have checked I could arrive at my Parisian Airbnb earlier in the day - I had to hang around for five hours in the heat before I could have a shower, properly relax, etc.

I had been warned not to rely on being able to obtain enough water en route on Sunday but whilst most shops were indeed shut I saw a bustling tabac or boulangerie at least once every 20km so one would never be truly stuck.

Route-wise, the surburbs of London and Paris are both equally dismal and unmotivating and there is about 50km of rather uninspiring and exposed riding on the D915.

However, «L'Avenue Verte» is fantastic even in the pitch-black and the entire trip was worth it simply for the silent and beautiful Normandy sunrise. I will be back.

Categories: LUG Community Blogs

Steve Kemp: Writing your own e-books is useful

Planet HantsLUG - Wed, 08/10/2014 - 20:03

Before our recent trip to Poland I took the time to create my own e-book, containing the names/addresses of people to whom we wanted to send postcards.

Authoring ebooks is simple, and this was a useful use. (Ordinarily I'd have my contacts on my phone, but I deliberately left it at home ..)

I did mean to copy and paste some notes from wikipedia about transport, tourist destinations, etc, into a brief guide. But I forgot.

In other news the toy virtual machine I hacked together got a decent series of updates, allowing you to embed it and add your own custom opcode(s) easily. That was neat, and fell out naturely from the switch to using function-pointers for the opcode implementation.

Categories: LUG Community Blogs

Steve Kemp: Before I forget, a simple virtual machine

Planet HantsLUG - Sun, 05/10/2014 - 09:34

Before I forget I had meant to write about a toy virtual machine which I'ce been playing with.

It is register-based with ten registers, each of which can hold either a string or int, and there are enough instructions to make it fun to use.

I didn't go overboard and write a complete grammer, or a real compiler, but I did do enough that you can compile and execute obvious programs.

First compile from the source to the bytecodes:

$ ./compiler examples/loop.in

Mmm bytecodes are fun:

$ xxd ./examples/loop.raw 0000000: 3001 1943 6f75 6e74 696e 6720 6672 6f6d 0..Counting from 0000010: 2074 656e 2074 6f20 7a65 726f 3101 0101 ten to zero1... 0000020: 0a00 0102 0100 2201 0102 0201 1226 0030 ......"......&.0 0000030: 0104 446f 6e65 3101 00 ..Done1..

Now the compiled program can be executed:

$ ./simple-vm ./examples/loop.raw [stdout] register R01 = Counting from ten to zero [stdout] register R01 = 9 [Hex:0009] [stdout] register R01 = 8 [Hex:0008] [stdout] register R01 = 7 [Hex:0007] [stdout] register R01 = 6 [Hex:0006] [stdout] register R01 = 5 [Hex:0005] [stdout] register R01 = 4 [Hex:0004] [stdout] register R01 = 3 [Hex:0003] [stdout] register R01 = 2 [Hex:0002] [stdout] register R01 = 1 [Hex:0001] [stdout] register R01 = 0 [Hex:0000] [stdout] register R01 = Done

There could be more operations added, but I'm pleased with the general behaviour, and embedding is trivial. The only two things that make this even remotely interesting are:

  • Most toy virtual machines don't cope with labels and jumps. This does.
    • Even though it was a real pain to go patching up the offsets.
    • Having labels be callable before they're defined is pretty mandatory in practice.
  • Most toy virtual machines don't allow integers and strings to be stored in registers.
    • Now I've done that I'm not 100% sure its a good idea.

Anyway that concludes todays computer-fun.

Categories: LUG Community Blogs

Steve Kemp: Kraków was nice

Planet HantsLUG - Sat, 04/10/2014 - 13:20

We returned safely from Kraków, despite a somewhat turbulent flight home.

There were many pictures taken, but thus far I've only posted a random night-time shot. Perhaps more will appear in the future.

In other news I've just made a new release of the chronicle blog compiler, So 5.0.7 should shortly appear on CPAN.

The release contains a bunch of minor fixes, and some new facilities relating to templates.

It seems likely that in the future there will be the ability to create "static pages" along with the blog-entries, tag-clouds & etc. The suggestion was raised on the github issue tracker and as a proof of concept I hacked up a solution which works entirely via the chronicle plugin-system, proving that the new development work wasn't a waste of time - especially when combined with the significant speedups in the new codebase.

(ObRandom: Mailed the Debian package-mmaintainer to see if there was interest in changing. Also mailed a couple of people I know who are using the old code to see if they had comments on the new code, or had any compatibility issues. No replies from either, yet. *shrugs*)

Categories: LUG Community Blogs

Ben Francis: What is a Web App?

Planet ALUG - Fri, 03/10/2014 - 17:50

What is a web app? What is the difference between a web app and a web site? What is the difference between a web app and a non-web app?

In terms of User Experience there is a long continuum between “web site” and “web app” and the boundary between the two is not always clear. There are some characteristics that users perceive as being more “app like” and some as more “web like”.

The presence of web browser-like user interface elements like a URL bar and navigation controls are likely to make a user feel like they’re using a web site rather than an app for example, whereas content which appears to run independently of the browser feels more like an app. Apps are generally assumed to have at least limited functionality without an Internet connection and tend to have the concept of residing in a self-contained way on the local device after being “installed”, rather than being navigated to somewhere on the Internet.

From a technical point of view there is in fact usually very little difference between a web site and a web app. Different platforms currently deal with the concept of “web apps” in all sorts of different, incompatible ways, but very often the main difference between a web site and web app is simply the presence of an “app manifest”. The app manifest is a file containing a collection of metadata which is used when “installing” the app to create an icon on a homescreen or launcher.

At the moment pretty much every platform has its own proprietary app manifest format, but the W3C has the beginnings of a proposed specification for a standard “Manifest for web applications” which is starting to get traction with multiple browser vendors.

Web Manifest – Describing an App

Below is an example of a web app manifest following the proposed standard format.

http://example.com/myapp/manifest.json:

{ "name": "My App", "icons": [{ "src": "/myapp/icon.png", "sizes": "64x64", "type": "image/png" }], "start_url": "/myapp/index.html" }

The manifest file is referenced inside the HTML of a web page using a link relation. This is cool because with this approach a web app doesn’t have to be distributed through a centrally controlled app store, it can be discovered and installed from any web page.

http://example.com/myapp/index.html:

<!DOCTYPE html> <html> <head> <title>My App - Welcome</title> <link rel="manifest" href="manifest.json"> <meta name="application-name" content="My App"> <link rel="icon" sizes="64x64" href="icon.png"> ...

As you can see from the example, these basic pieces of metadata which describe things like a name, an icon and a start URL are not that interesting in themselves because these things can already be expressed in HTML in a web standard way. But there are some other other proposed properties which could be much more interesting.

Display Modes – Breaking out of the Browser

We said above that one thing that makes a web app feel more app like is when it runs outside of the browser, without common browser UI elements like the URL bar and navigation controls. The proposed “display” property of the manifest allows authors of web content which is designed to function without the need for these UI elements to express that they want their content to run outside of the browser.

http://example.com/myapp/manifest.json:

{ "name": "My App", "icons": [{ "src": "/myapp/icon.png", "sizes": "64x64", "type": "image/png" }], "start_url": "/myapp/index.html" "scope": "/myapp" "display": "standalone" }

The proposed display modes are “fullscreen”, “standalone”, “minimal-ui” and “browser”. The “browser” display mode opens the content in the user agent’s conventional method (e.g. a browser tab), but all of the other display modes open the content separate from the browser, with varying levels of browser UI.

There’s also a proposed “orientation” property which allows the content author to specify the default orientation (i.e. portrait/landscape) of their content.

App Scope – A Slice of the Web

In order for a web app to be treated separately from the rest of the web, we need to be able to define which parts of the web are part of the app, and which are not. The proposed “scope” property of the manifest defines the URL scope to which the manifest applies.

By default the scope of a web app is anything from the same origin as its manifest, but a single origin can also be sliced up into multiple apps or into app and non-app content.

Below is an example of a web app manifest with a defined scope.

http://example.com/myapp/manifest.json:

{ "name": "My App", "icons": [{ "src": "/myapp/icon.png", "sizes": "64x64", "type": "image/png" }], "start_url": "/myapp/index.html" "scope": "/myapp" }

From the user’s point of view they can browse around the web, seamlessly navigating between web apps and web sites until they come across something they want to keep on their device and use often. They can then slice off that part of the web by “bookmarking” or “installing” it on their device to create an icon on their homescreen or launcher. From that point on, that slice of the web will be treated separately from the browser in its own “app”.

Without a defined scope, a web app is just a web page opened in a browser window which can then be navigated to any URL. If that window doesn’t have any browser-like navigation controls or a URL bar then the user can get stranded at a dead on the web with no way to go back, or worse still can be fooled into thinking that a web page they thought was part of a web app they trust is actually from another, malicious, origin.

The web browser is like a catch-all app for browsing all of the parts of the web which the user hasn’t sliced off to use as a standalone app. Once a web app is registered with the user agent as managing a defined slice of the web, the user can seamlessly link into and out of installed web apps and the rest of the web as they please.

Service Workers – Going Offline

We said above that another characteristic users often associate with “apps” is their ability to work offline, in the absence of a connection to the Internet. This is historically something the web has done pretty badly at. AppCache was a proposed standard intended for this purpose, but there are many common problems and limitations of that technology which make it difficult or impractical to use in many cases.

A new, much more versatile, proposed standard is called Service Workers. Service Workers allow a script to be registered as managing a slice of the web, even whilst offline, by intercepting HTTP requests to URLs within a specified scope. A Service Worker can keep an offline cache of web resources and decide when to use the offline version and when to fetch a new version over the Internet.

The programmable nature of Service Workers make them an extremely versatile tool in adding app-like capabilities to web content and getting rid of the notion that using the web requires a persistent connection to the Internet. Service Workers have lots of support from multiple browser vendors and you can expect to see them coming to life soon.

The proposed “service_worker” property of the manifest allows a content author to define a Service Worker which should be registered with a specified URL scope when a web app is installed or bookmarked on a device. That means that in the process of installing a web app, an offline cache of web resources can be populated and other installation steps can take place.

Below is our example web app manifest with a Service Worker defined.

http://example.com/myapp/manifest.json:

{ "name": "My App", "icons": [{ "src": "/myapp/icon.png", "sizes": "64x64", "type": "image/png" }], "start_url": "/myapp/index.html" "scope": "/myapp" "service_worker": { "src": "app.js", "scope": "/myapp" } } Packages – The Good, the Bad and the Ugly

There’s a whole category of apps which many people refer to as “web apps” but which are delivered as a package of resources to be downloaded and installed locally on a device, separate from the web. Although these resources may use web technologies like HTML, CSS and Javascript, if those resources are not associated with real URLs on the web, then in my view they are by definition not part of a web app.

The reason this approach is commonly taken is that it allows operating system developers and content authors to side-step some of the current shortcomings of the web platform. Packaging all of the resources of an app into a single file which can be downloaded and installed on a device is the simplest way to solve the offline problem. It also has the convenience that the contents of that package can easily be reviewed and cryptographically signed by a trusted party in order to safely give the app privileged access to system functions which would currently be unsafe to expose to the web.

Unfortunately the packaged app approach misses out on many of the biggest benefits of the web, like its universal and inter-linked nature. You can’t hyperlink into a packaged app, and providing an updated version of the app requires a completely different mechanism to that of web content.

We have seen above how Service Workers hold some promise in finally solving the offline problem, but packages as a concept may still have some value on the web. The proposed “Packaging on the Web” specification is exploring ways to take advantage of some of the benefits of packages, whilst retaining all the benefits of URLs and the web.

This specification does not explore a new security model for exposing more privileged APIs to the web however, which in my view is the single biggest unsolved problem we now have left on the web as a platform.

Conclusions

In conclusion, a look at some of the latest emerging web standards tells us that the answer to the question “what is a web app?” is that a web app is simply a slice of the web which can be used separately from the browser.

With that in mind, web authors should design their content to work just as well inside and outside the browser and just as well offline as online.

Packaged apps are not web apps and are always a platform-specific solution. They should only be considered as a last resort for apps which need access to privileged functionality that can’t yet be safely exposed to the web. New web technologies will help negate the need for packages for offline functionality, but packages as a concept may still have a role on the web. A security model suitable for exposing more privileged functionality to the web is one of the last remaining unsolved challenges for the web as a platform.

The web is the biggest ecosystem of content that exists, far bigger than any proprietary walled garden of curated content. Lots of cool stuff is possible using web technologies to build experiences which users would consider “app like”, but creating a great user experience on the web doesn’t require replicating all of the other trappings of proprietary apps. The web has lots of unique benefits over other app platforms and is unrivalled in its scale, ubiquity, openness and diversity.

It’s important that as we invent cool new web technologies we remember to agree on standards for them which work cross-platform, so that we don’t miss out on these unique benefits.

The web as a platform is here to stay!

Categories: LUG Community Blogs

XDA Developer Conference 2014

Planet SurreyLUG - Wed, 01/10/2014 - 11:09

The XDA Developer community had its second conference last weekend, this time in Manchester, UK. We were asked to sponsor the event and were happy to do so. I went along with Daniel Holbach from the Community Team and Ondrej Kubik from the Phone Delivery Team at Canonical.

This was my first non-Ubuntu conference for a while, so it was interesting for me to meet people from so many different projects. As well as us representing Ubuntu Phone, there were guys from the Jolla project showing off SailfishOS and their handset and ports. Asa Dotzler was also there to represent Mozilla & FirefoxOS.

Daniel did a small Ubuntu app development workshop which enabled us to learn a lot from our materials and process around App Dev Schools which we’ll feed back to later sessions. Ondrej gave a talk to a packed room about hardware bring-up and porting Ubuntu to other devices. It was well receieved and explained the platform nicely. I talked about the history of Ubuntu phone and what the future might hold.

There were other sponsor booths including big names like nVidia showing off the Sheild tablet and Sony demonstrating their rather bizarre Smart EyeGlass technology. Oppo and OnePlus had plenty of devices to lust after too including giant phones with beautiful displays. I enjoyed a bunch of the talks including MediaTek making a big announcement, and demonstrating their new LinkIT One platform.

The ~200 attendees were mostly pretty geeky guys whose ages ranged from 15 to 50. There were Android developers, ROM maintainers, hardware hackers and tech enthusiasts who all seemed very friendly and open to discuss all kinds of tech subjects at every opportunity.

One thing I’d not seen at other conferences which was big at XDA:DevCon was the hardware give-aways. The organisers had obtained a lot of tech from the sponsors to give away. This ranged from phone covers through bluetooth speakers, mobile printers, hardware hacking kits through to phones, smart watches & tablets, including an Oppo Find 7, pebble watch and nVidia Sheild & controller. These were often handed out as a ‘reward’ for attendees asking good questions, or as (free) raffle prizes. It certainly kept everyone on their toes and happy! I was delighted to see an Ubuntu community member get the Oppo Find 7 I was rewarded with an Anker MP141 Portable Bluetooth Speaker during one talk for some reason

On the whole I found the conference to be an incredibly friendly, well organised event. There was plenty of food and drink at break times and coffee and snacks in between with relaxing beers in the evening. A great conference which I’d certainly go to again.

Categories: LUG Community Blogs
Syndicate content