sources
Subscribe
OPMLPowered by Perlanet
The slides from a half-day workshop on career development for programmers that I ran at The Perl Conference in Glasgow
Over the last few months, I’ve noticed that I’ve created a few quick and dirty websites using GitHub Pages. And when I mentioned the latest one on Twitter yesterday, a friend asked if I could take the time to explain how I did it. Which, of course, I’m very happy to do.
Do you mind sharing the knowledge in a step-by-step instructions, please?
— Mohammad S Anwar (@cpan_author) August 25, 2018
Let’s start with a couple of caveats. Firstly, GitHub Pages is a service provided by GitHub (the clue is in the name). If you’re not comfortable with the idea of source code control, Git and GitHub then GitHub Pages probably isn’t the best place for you to host your simple static websites. Secondly, GitHub Pages were originally introduced to enable Open Source Software projects to have a quick and easy way to create a good-looking website to market their wares. I’m not sure how happy GitHub is that people are using their services to host free websites. So please don’t take liberties with their generosity. If you’re planning to create a site that will be heavily visited or that you will make a load of money from, then please look elsewhere for hosting.
With that all out of the way, perhaps I should explain what GitHub Pages are.
GitHub Pages is a service provided by GitHub which allows you to create simple static websites and host them on GitHub’s infrastructure. You can use a static site generator called Jekyll to build your website automatically whenever you change your input files or you can use some other system to build your site (including maintaining all the HTML files manually – which I really don’t recommend).
Our first (very simple) site
Each GitHub Pages site is built from a GitHub code repository (“repo” for short), so we’ll start by creating a new repo (mine was called simple-website). Use whatever workflow you usually prefer to create a new repo and add to it a file called index.md. Jekyll works with a text markup system called Markdown, so you’ll need to pick up a bit of that (it’s really not hard – which is pretty much why it was created). My file looks like this:
# Simple Test Website This site is built on [GitHub pages](https://pages.github.com/), so the source code is [available on GitHub](https://github.com/davorg/simple-website/). (Made by [@davorg](https://twitter.com/davorg))
Once you have committed this file and pushed it back to GitHub, we’re ready to turn on GitHub Pages support for your repo. Go to the “settings” page for your repo and scroll down until you find the GitHub Pages section which will look like this:
Change the “source” dropdown to “master branch” and hit save. The section will change to look like this:
You’ll see that the information includes a link to your new site. It will be https://your-github-username.github.io/your-repo-name/. If you click on that link, you’ll see your site. In my case, it looked like this:
That is the default look of a website that is generated from Markdown file by Jekyll. It’s certainly simple, but there are ways that we can improve it with very little effort. For a start, we can add a Jekyll theme. That’s a button on the GitHub Pages settings. I chose the “Slate” theme and almost immediately, my website changed to look like this:
Notice that the theme has added a few more pieces of information taken from the repo’s metadata If you look at your code, you’ll see that the theme chooser has simply added a file called _config.yml to your repo. That file will become more important if you choose to dig further into Jekyll.
You’ll also see that your GitHub Pages is automatically served over HTTPS – so you get all the security and SEO boosts that brings.
From here, there are a few ways to go in order to improve our site:
- We can add more pages to the site by adding more Markdown files
- We can dig deeper into Jekyll and make more use of its features
- We can abandon Jekyll and switch to a different static site generator
- We can start to use a custom domain for our website
I plan to cover some of these options in other articles.
The post Simple Static Websites With GitHub Pages appeared first on Davblog.
Yesterday (despite the best efforts of Virgin Trains to stop me) I came home from The Perl Conference in Glasgow. I had a great week up in Glasgow, and I thought I’d better write about it before I forgot anything important.
Pre-Conference
I arrived on Sunday evening. This was the last day of the European Championships which were jointly hosted in Glasgow and Berlin. As I was checking into my hotel, the receptionist happened to mention that there was some celebration of the championships in George Square so, once I had unpacked, I went off to explore. And I found a free festival with lots of great music. It had been going all day, so I only got to see the last couple of acts (Fatoumata Diawara and Shooglenifty) but it was a great way to spend my first couple of hours in the City.
The following day, I had agreed to meet Andrew Solomon (of Geek Uni) at the conference venue so we could see what the place was like before our workshops on Tuesday. Having done that, we went off to explore the city a bit. Following lunch (which was at the excellent Pizza Punks) we retired to our respective hotel rooms to ensure that our workshops were ready. That, at least, was the plan. When I got back to my hotel, I found that my room hadn’t been cleaned, so I set out for another walk. This time I found what’s left of the Glasgow School of Art and King Tut’s.
Workshops
On Tuesday, I spent the day at the venue, running two half-day workshops. In the morning I introduced a smallish class to the joys of on-page SEO and in the afternoon a slightly larger class sat through my rather experimental “The Professional Programmer” workshop. This was a quick look at some of the things that a professional programmer needs to understand other than programming itself. Both workshops seemed to go pretty well and I’m looking forward to reading the feedback.
That evening, the pre-conference social was held in the venue, so following my workshop, I just had to wander upstairs to meet loads of old friends. Much good food and conversation was enjoyed over the following few hours.
Day 1
Traditionally, the first order of business on the first day of the conference is the announcement of next year’s venue. Thomas of the YAPC Europe Foundation announced that we’ll be going back to Riga in 2019. I’m already looking forward to it.
Then the talks started. Ruth Holloway’s keynote “Discourse Without Drama” proposed a world where we can talk about things (even disagree about things) without every conversation ending in anger and shouting. I’m sure it’s a world that most of us would love to see.
For the rest of the morning, I saw Salve Nilsen talking about the state of Perl Mongering in Europe, Choroba discussing the inconsistencies in type handling between the different versions of various JSON libraries and Leon Timmermans explaining how the Perl 5 Porters have handled language design in recent years. For the last slot of the morning, I saw Makoto Nazaki give an update on what is happening in The Perl Foundation.
After a really good lunch (the venue staff were good at many things – catering was top of the list) I saw Curtis Poe talking about the best ways to sell a legacy code clean-up project to your managers. This was followed by Ben Edwards explaining how Pirum keep their CVS and Git code repositories in step.
The conference day ended with the lightning talks. This included me giving an overview of the twenty year history of London Perl Mongers in five minutes. I think it worked.
Then I made a mistake. The conference dinner was in a restaurant about a forty minute walk or twenty minute taxi ride away. I was due there at about 7:30pm. I went back to my hotel room and got there at about 6pm and laid on my bed for a few minutes. When I woke up and looked at the time, it was 8pm. I could have rushed around and made a late appearance at the dinner, but I decided to take note of what my body obviously wanted and had a quiet night in.
Day 2
Feeling refreshed after a long sleep, I attacked day two of the conference. I started by listening to Thomas Klausner explaining how he has written an asynchronous web application without using any of the usual frameworks. It looked interesting and I’ll be investigating his code in more detail. Following that, I saw André Walker talking about how error messages can be so much easier to understand. He had an example from a module that he had written. It did look good. I then saw Mohammed Anwar encouraging people to follow his lead and submit pull requests to CPAN modules. As someone who has been on the receiving end of many of Mohammed’s pull requests, I can only agree that I’d love to see more people sending me improvements to my code. I try to see at least one Perl 6 talk at every conference I go to and this time I chose my former colleague, Simon Proctor, explaining function signatures, multi-methods and things like that.
I didn’t see much of lunch on Thursday as Andrew Solomon had arranged a “Birds of a Feather” session on “Growing a Perl Team”. A large group of like-minded people (but from many different parts of the industry) talked about the problems they have attracting and keeping good Perl developers. I’m not sure we came up with a clear way forward, but it was certainly good to share ideas.
The afternoon started with Mark Fowler talking though the entries from last year’s Perl Advent Calendar (and asking us to propose articles for this year’s calendar) and I followed that with Andrew Solomon telling us about his experience of running on-the-job Perl training for various companies. Following a coffee break, I saw Tom Hukins explaining what WebDriver is and how to using it with Perl. After that was my talk about the Line of Succession web site. I didn’t get a huge audience, but those that were there seemed to enjoy it.
Then there was a slightly different session. Every year, Larry Wall goes to lots of Perl conferences. And his wife, Gloria, always comes with him. Normally, Larry gives a keynote and Gloria watches from the audience. When he was organising this conference, Mark Keating decided to turn that on its head. He didn’t invite Larry to speak and, instead, asked Gloria to talk to the conference. So we had fifty minutes of Gloria Wall in conversation with Curtis Poe. And it was a really interesting conversation. I recommend you look for the video.
Once again, the day ended with an interesting selection of lightning talks.
Day 3
Friday was good. Friday was the day that I wasn’t speaking. And that meant that Friday was the day I didn’t need to carry my laptop around all day.
I started by watching Wesley Schwengle talking about using Docker with Perl. I keep going to talks like this. Every time I get that little bit closer to understanding how Docker is going to make my life easier. Then I switched to something far less technical and saw Joelle Maslak explaining how mistakes that we all make can make our applications less usable for many people. I followed that with Lee Johnson introducing Burp Scanner and explaining how it finds insecurities in web applications and Ruth Holloway talking about accessibility at conferences and events. I think the people who attended it all found it interesting – it’s a shame that, as far as I could see, not many of them were event organisers.
After lunch I watched Matt Trout introduce Babble, a Perl module that can help you deal with syntax differences between different versions of Perl. Then the final keynote was Curtis Poe talking about some of the possible futures for Perl 5 and 6. After that, there was just another great selection of lightning talks before Mark Keating closed the conference by thanking everyone.
I couldn’t stay around for the post-conference goodbyes as I had to get to Edinburgh to see Amanda Palmer in concert. That was excellent too.
When I heard that Mark would be organising the conference, I knew we’d be in safe hands. Mark has plenty of experience of this and he’s great at it. Of course, he had a great team working with him too and I think it really helped that he chose a professional conference venue to host it.
So huge thanks to Mark and his team. But thanks, also, to all of the speakers and the sponsors. I’m sure all the attendees will agree that this year’s conference was outstanding.
See you all in Riga.
The post The Perl Conference in Glasgow appeared first on Perl Hacks.
For most of last week I was out of London running three days of Perl training for… well, I probably shouldn’t name them, so let’s just call them a well-known British educational establishment. The photo above is a big clue.
The people I was training were IT support staff; the people who keep many of the organisation’s IT systems running. They were a mixture of sysadmins, DBAs and developers. What they had in common was that at least part of their working life is spent looking after systems that are written in Perl and they had never before taken any formal training in the language.
In my experience, this is a pretty common situation. Because Perl is “just a scripting language”, I often come across people who are responsible for Perl programs but who have never been taught how the language works. Managers often seem to believe that people will absorb Perl knowledge just by being exposed to the code. And, of course, that’s partly true. On the face of it, Perl isn’t particularly hard to understand. If you have a grounding in other programming languages in the C/Algol family or you know a bit about Unix tools like awk, sed or Bash scripts you can certainly be productive in Perl.
But not as productive as you could be if you actually took the time to learn about the language.
In many ways, this is one of my favourite kinds of training. The course ran for three days and was adapted from my Introduction to Perl and Intermediate Perl courses. It’s a lot of fun taking the attendees right back to basic Perl and slowly building up their knowledge. The three days is an almost constant stream of “light-bulb moments” as students connect the concepts that I’m talking to code that they’ve seen in the systems they maintain. While it’s true that you can maintain a Perl program just using knowledge that you’ve worked out from reading the code, you become a lot more effective when you understand more of the underlying concepts.
On the other hand, it can be a slightly frustrating kind of course to run. In many cases, they code that these people are maintaining was originally written by people who had never really understood Perl and it has been maintained for years by people with even less knowledge of the language. So the code is a long way from the modern Perl that we’d all like to spend our days working on. This is often going to be monolithic code bases with no sign of a “use strict” or “use warnings”. Maintenance of this code is often seen as a low priority task that is only undertaken when changes are vital and it’s unlikely that anyone could ever take the time that would be required to raise the standards of this code.
But, nevertheless, I feel that over the last few days I have increased the average level of Perl knowledge in the world. There are eight more people who know how Perl references work (and why you might use them). That has to be a net win. And the fact that the organisation was happy to pay me to run the course must be seen as a positive. It means that they value the effectiveness of their developers.
I often hear people worried about the lack of people starting to use Perl. I’ve lost count of the number of developer managers or CTOs who have cited the lack of available Perl talent as the reason they are moving their development to other technologies. But there is another option. Employ people with good general Programming skills and run training courses that give them the more specific Perl skills that they mean.
I know a good trainer who would be happy to help!
The post Introducing People to Perl appeared first on Perl Hacks.
(The image above was the first result I got when searching Google Images for a CC-licensed image for “professional programmer”.)
Two weeks ago, I wrote about the SEO workshop I’m running on Tuesday morning just before The Perl Conference in Glasgow this August. Today, I’d like to give a few more details about the other workshop I’m running that day. After lunch, I’m running a workshop called “The Professional Programmer”. What’s that about?
I came into programming through what was a very traditional route. I did a degree in Computer Studies which I finished in 1988. And for the last thirty years I’ve been working as a programmer for a number of different companies from tiny start-ups to huge multi-nationals.
But more and more, I’m working with people who didn’t come through the same route. It’s very common that I’ll be working with people who don’t have a degree. And it’s rare that I’ll work with someone who’s been in the industry as long as I have (for I am an Old Man). I’m not saying for a second that those people aren’t just as capable of doing the job as I am. But I am saying that I know stuff that some of those people won’t have worked out yet.
This certainly isn’t going to be me telling you stuff that I learned on my degree. To be honest, I can’t think of much on my degree that I’ve used in my career. On my degree course, SQL was introduced as a cutting-edge technology (one lecturer even described it as a reporting tool that could be used by end-users!) We also did classes on COBOL and Assembler. No, there’s very little there that would be of much interest to people working in the modern software industry.
A few days ago, I started to sketch out some of the things I might want to talk about. I think the plan is going to be that we start with some of the technologies that sit alongside the programming that we all do every day and slowly move away from hard tech into the fluffier areas of the industry that we work in. Here are some of the topics I hope to cover.
Adjacent Technologies
Ok, we all have a programming language or two under our belts. But what else do we need to know?
How well do you know the operating systems that you work on? What, for example, is the most obscure Unix tool that you know? At what level do you understand the networking features that your code almost certainly makes use of? Can you debug network connectivity problems? To what level of detail do your really know the HTTP request-response cycle?
What data storage systems do you use? How well do you know SQL? Do you use No SQL systems as part of your technology stack? If not, could you? Do you cache things at the right level in your application? Should you be caching more things? Do you have a CDN? Do you know what a CDN is and what it does for you?
Are you an expert in the tools that you use every day? I don’t care if you prefer vi or emacs (or, I suppose, anything else), but are you an expert in using your editor? I’m happy to admit this is one area where I fall short. I bounce between many different editors and I’ve never really become an expert in any of them.
Are you the person in your team that people come to with git questions? Or do you just know half a dozen commands that seem to do approximately the right thing most of the time? Your source code control system is a vital part of your workflow. Get to know it well.
How well do you know your continuous integration environment? Do you know which buttons to press to get a release built? Or are you the person who is constantly tweaking and improving the Jenkins jobs that power the release process? And what underlies your release process? Are you building RPMs or some other type of package or do you build a new Docker container and deploy that in the cloud? How well do you know the cloud provider that you’re using? Are there new AWS features that could replace parts of your existing infrastructure? (The answer to that question is always yes.)
How good are your tests? What’s your unit test coverage? How many different types of automated testing does your system use? Do you know the difference between unit tests and integration tests? What tools are you using for automated testing? How well do you know how to use them? Is there something better out there?
Software Engineering & Architecture
What level are you involved in architectural decisions? How do you decide on a design for your application? Are you using largely procedural code or does your system make good use of classes? Is it possible for a system to be too object-oriented? How do you know when you’ve crossed that boundary?
How is your knowledge of design patterns? Do you know what a factory class is? Do you know why you would use one? Have you ever written one? Do you have an opinion on MVC designs? What is good and bad about the frameworks that you use? What would you like to do differently?
Are you maintaining a monolithic codebase from fifteen years ago? Do you have a plan to modernise your code? Have you implemented any microservices yet? How do you go about replacing small parts of a monolith with microservices? What are the advantages of a microservices architecture?
Is your team using an agile software development methodology? Is it Scrum, Kanban, XP or do you just cherry-pick bits from all of them? Is your team really agile or do you just pay lip service to agile techniques? Are you self-managing? How accurate are your estimates? Can you improve that? How well do you know the Agile Manifesto? To what extent do you agree with it?
The Business
What does your company do? What does success look like? How does what you do contribute to that success? How well do you understand the business? Do you have suggestions for improving the business outside of your team?
Do you understand the environment that the company operates in? What do you know about the economic pressures on the company? Is the company publicly or privately owned? Do you have shares in the company? Do you know what they are worth?
Personal Development
What level are you currently at? Do you know what you need to do in order to progress in the company? Do you have a plan to achieve that? Do you have a mentor inside the company who can help you come up with that plan? Will the company give you budget for training and personal development?
Do you need to communicate with business people inside the company? How good is your written and spoken English? Do you know how to use apostrophes? Do you need to give presentations to people in the company? How comfortable are you with public speaking? Can you get better at that?
How well-known are you outside of the company? Can you blog about your technical expertise? (You probably need to be careful if you’re blogging about stuff you do at work.) Do you speak at conferences? Should you start speaking at conferences?
As you can see, when I start writing this stuff down, it can easily all get a bit “stream of consciousness”. Hopefully in the five weeks between now and the workshop, I can tie it down and impose a little more structure on it.
But not too much structure. I’d like to keep this pretty loose. I want the workshop to be very much a two-way discussion.
I hope that sounds interesting to some of you. The workshop will be in the afternoon of Tuesday 14th August. To attend any of the workshops, you’ll need to buy an extra ticket. Tickets for either of my half-day workshops are £75.
I hope to see some of you there. Please let me know in the comments if you have any questions about this workshop.
The post Professional Programmer is Professional appeared first on Perl Hacks.
I thought it might be interesting to talk about some of the topics I’ll be covering at my workshops at The Perl Conference in Glasgow in August. Today I’ll be talking about the Web Site Tune-Up workshop and in my next post, I’ll cover The Professional Programmer.
And I thought it would be most useful to show you a case study of where I’ve done some work to tune up a web site. So here’s the story of some work I’ve done on the web site for The Perl Conference in Glasgow itself.
When the site first went live, I noticed that it didn’t have any Open Graph tags. Open Graph tags are a series of HTML elements that you can add to the
of a web page which tell sites like Facebook interesting things about the page. Most usefully, they can tell Facebook and Twitter which image and text to use when someone shares a link to your site. Obviously, we all want people to share our URLs as widely as possible and having a nice image and a useful description show up when the site is shared is a good way to encourage more sharing (and as I’ve been typing that, I’ve just realised that actually having obvious sharing buttons on the page is another good idea – more work to do there!)So I needed to find the right place to add these tags. Most web sites are generated by a content management system. Most Perl conference sites us A Conference Toolkit, So I just needed to look through the conference repo to find the template that generates the header of the page and edit that. Here’s the first commit I made, which just added hard-coded values for the tags. With this in place, the tags looked like this:
<meta property="og:title" content="The Perl Conference - Glasgow 2018" /> <meta property="og:type" content="website" /> <meta property="og:url" content="http://act.perlconference.org/tpc-2018-glasgow/" /> <meta property="og:image" content="http://act.perlconference.org/tpc-2018-glasgow/css/logos/lrg-conf-logo.png" />
That was an improvement, but there were a few problems. Firstly, it was missing a couple of tags that Twitter likes to use, so I added those in this commit. Then I noticed I had forgotten the description (which prevented Twitter from parsing the data correctly). This commit fixed that.
And there it sat until quite recently. But last weekend I decided I needed to fix those hard-coded values. I noticed the problem when I shared a link to the workshops page on Facebook and my post contained information about the home page.
This took a bit more digging. I had to understand a little more about the internals of ACT. But over a series of small commits last weekend, I got it working as I wanted. Actually, not quite as I wanted – the Wiki URLs are still not working properly, I’ll get back to those later on. I also want to change the description on every page – but I’m not sure if that’s possible in ACT.
This weekend we published an initial version of the schedule for the conference – one that only covers the workshops (as those are the only talks with firm dates yet). Initially, it didn’t look very nice as the standard ACT template for the schedule page shows unscheduled talks before scheduled ones. That didn’t make much sense to me as there is a huge list of unscheduled talks and it seemed unlikely that anyone would ever scroll past that to find the scheduled talks. You should also bear in mind that Google is the most important visitor to your page and Google assumes that the most important content on your page comes first. So changing the order is likely to give us an SEO boost.
So I wanted to find a way to fix that. And that turned out to be harder than expected. It turns out that ACT is built on layers of templates. If your ACT instance doesn’t have a particular template, then the default one is used. And it looks like most people just use the default schedule template. But once I had copied that template into our repository, I was free to edit it any way I wanted. I started by doing the re-ordering that I mentioned above. Then I started to consider other options.
Firstly, the default formatting of the schedule on a ACT site is a little ugly. But I knew that the TPC Glasgow site was built using Bootstrap. So I knew that I could use Bootstrap’s table classes to make the schedule table look a little nicer. That was just a case of adding some classes to the template that generates the table (and, actually, removing quite a lot of unnecessary classes and presentation mark-up – removing presentation mark-up is another good tip for SEO).
Finally, I wanted to change the order of the data in each cell of the presentation table. Remember when I said above that the most important data should come first? Well, if you’re presenting data about a conference talk, what’s the most important piece of information? The default template showed the speaker’s name before the title of the talk. I wanted to reverse that (I also wanted to split the data across several lines). It turned out that this mark-up was in another template which contained a number of “utility” macros that I had to copy into our repo. But once I had done that, it was simple to make the changes I wanted. The current version of the schedule layout is in the image at the top of this post. I hope you agree it looks nicer that the old version.
So that’s where I’ve got to. There are a few other fixes I’d like to make:
- Fix the Open Graph tags for the Wiki (they’re broken currently because the URL includes parameters)
- Add variable descriptions to the Open Graph tags (if ACT can be made to support it)
- Add more prominent (and more varied) sharing buttons to the pages
- Add structured data to the schedule pages, so that Google has a better chance of knowing what the pages are about.
But that’s a pretty good example of the kinds of things I’ll be talking about in my Web Site Tune-Up workshop. To summarise what I’ve done:
- Added OpenGraph tags to all pages
- Restructured the schedule pages so the most important information comes first
- Moved towards using more semantic mark-up and removed presentation mark-up
- Reordered the data for each talk so readers (including Google) know what the most important data item is
This only touches on the kind of information I’ll be covering in the workshop. There will be dozens more practical tips you can use to improve Google’s understanding of your web site.
The half-day workshop takes place on Tuesday 14th August from 09:30-13:00. Tickets are available when you book your ticket for the main conference and cost £75.
Hope to see you there.
The post Web Site Tune-Up: A Case Study appeared first on Perl Hacks.
When I signed up for my Monzo bank account last year, one of the things that really excited me was the API they made available. Of course, as is so often the way with these things, my time was taken up with other things and I never really got any further than installing the Perl module that wrapped the API.
The problem is that writing code against an API takes too long. Oh, it’s generally not particularly difficult, but there’s always something that’s more complicated than you think it’s going to be.
So I was really interested to read last week that Monzo now works with IFTTT. IFTTT (“If This Then That”) is a service which removes the complexity from API programming. You basically plug services together to do something useful. I’ve dabbled with IFTTT before. I have “applets” which automatically post my Instagram photos to Twitter, change my phone’s wallpaper to NASA’s photo of the day, tell me when the ISS is overhead – things like that) so I knew this would be an easier way to do interesting things with the Monzo API – without all that tedious programming.
An IFTTT applet has two parts. There’s a “trigger” (something that tells the applet to run) and an “action” (what you want it to do). Monzo offers both triggers and actions. The triggers are mostly fired when you make a purchase with your card (optionally filtered on things like the merchant or the amount). The actions are moving money into or out of a pot (a pot in a Monzo account is a named, ring-fenced area in your account where you can put money that you want to set aside for a particular purpose).
You can use a Monzo trigger and action together (when I buy something at McDonald’s, move £5 to my “Sin Bin” pot) but more interesting things happen if you combine them with triggers and actions from other providers (move £5 into my “Treats” pot when I do a 5K run – there are dozens of providers).
I needed an example to try it out. I decided to make a Twitter Swear Box. The idea is simple. If I tweet a bad word, I move £1 from my main account into my Swear Box pot.
The action part is simple enough. Monzo provides an action to move money out of a pot. You just need to give it the name of the pot and the amount to move.
The trigger part is a little harder. Twitter provides a trigger that fires whenever I tweet, but that doesn’t let me filter it to look for rude words. But there’s also a Twitter Search trigger which fires whenever a Twitter search finds a tweet which matches a particular search criterion. I used https://twitter.com/search-advanced to work out the search string to use and ended up with “fudge OR pish OR shirt from:davorg”. There’s a slight problem here – it doesn’t find other versions of the words like “fudging” or “shirty” – but this is good enough for a proof of concept.
Creating the applet is a simple as choosing the services you want to use, selecting the correct trigger and action and then filling in a few (usually pretty obvious) details. Within fifteen minutes I had it up and running. I sent a tweet containing the word “fudge” and seconds later there was a pound in my Swear Box pot.
Tonight, I was at a meeting at Monzo’s offices where they talked about how they developed the IFTTT integration and what directions it might go in the future. I asked for the latitude and longitude of a transaction to be included in the details that IFTTT gets – I have a plan to plot my transactions on a map.
Monzo is the first bank to release an integration with IFTTT and it really feels like we’re on the verge of something really useful here. I’ll be great to see where they take the service in the future.
The post Monzo & IFTTT appeared first on Davblog.
It’s June, which means it’s only a couple of months until the Europe Perl community descends en masse on Glasgow for this year’s Perl Conference (formerly known as YAPC). For me, that also means I need to start planning the training courses I’ll be running before the conference. And for you, it means you need to start deciding which training courses you want to come to before the conference
This year, it looks like there will be one day of training courses on the day before the main conference starts (that’s Tuesday 14th August). There are a number of courses being offered – details are in a recent conference newsletter.
I’ll be giving two half-day courses and, unusually, there will be little or no Perl content in either of them. Here are the details:
Web Site Tune-Up: Improve Your Googlejuice
Many of us have web sites and for most web sites, success is measured by the number of visitors you get. And, in most of the western world, getting your web site to rank higher in Google’s search results is one powerful tool for bringing in more visitors.
In this half-day course, I’ll be introducing a number of simple tips that will make your site more attractive to Google which will, hopefully, improve your search ranking. If you make it easier for Google to understand the contents and structure of your site, then Google is more likely to want to send visitors to your site. (Other search engines are, of course, available but if you keep Google happy, you’ll be keeping them happy too.)
I ran a short version of this course at the London Perl Workshop last year. This version will be twice as long (and twice as detailed).
The Professional Programmer
Some people seem surprised that being really good at programming isn’t the only skill you need in order to have a successful career in software development.
I’ve been working in this industry for thirty years and I like to think I’ve been pretty successful. In this half-day course, I’ll look at some of the other skills that you need in order to do well in this industry. We’ll look at a range of skills from more technical areas like source code control and devops, to softer areas like software development methodologies and just working well with others.
I ran a two-hour version of this course at a London Perl Workshop in the dim and distant past. This version will be updated and expanded.
Both courses will be taking place on the same day. I’m not sure where they will be held, but I’ll let you know as soon as I have that information. Each half-day session costs £75 and you can book places on the conference web site. Places on the courses will be limited, so I recommend booking as soon as possible.
Do these courses sound interesting? Please let me know your thoughts in the comments.
The post Training in Glasgow appeared first on Perl Hacks.