- By Dan ThanhSometimes it is necessary to calculate the days of periodical events, like for instance sweepstakes, contests, regular publications, etc..
In general, it is an easy problem to solve. However when the events span multiple days and must not occur in holidays, the problem becomes less trival to solve.
Read this article to learn how you can use the PHP Sweepstakes class to compute the days of regular event taking in account these nuances that may complicate the calculations.
In terms of working, day 4 was actually only half a day. But since the last day of WeCamp would also just be half a day, some work had to be done. The team focussed on finishing their MVP and ended up actually finishing this as well! A great accomplishment for a team that, 4 days ago, did not know eachother at all.
After lunch the Pragmatist Survival Game was scheduled. We were randomly assigned team mates (get out of that little comfort zone you built during this week!) and went on to do four different games. The games were: A balance game to get team members over the water (preferably without falling in), trying to get as many floating items out of the water, making a fire and lighting gun powder with it and sword fighting. It was awesome to see everyone get into their pirate role so well, including the secret assignment each team got, which was to make a song or poem about Mikke One-Eye. For me personally it was fun to speak to and work with some people from outside of my team as well. And I succeeded pretty good in the whole “being a pirate” by stealing the tally stick of another team, thereby robbing them of the points they earned. Unfortunately our plan to add those points to our own points was stopped by the pirate leaders denying to add it to our points. Still, we earned a third place, which I think is pretty good, out of 8 teams.
Then it was time for the Enrise BBQ (which I was told by Eli should actually not be called a BBQ, but rather a grill-out). This was a perfect way to end the day with all attendees, plus some extra guests: Rick and Stefan from Enrise, Merel and a friend (Merel is the awesome graphical artist who did our coach avatars) and my wife and kids. The night ended in the big tipi around a campfire. I hear some people didn’t go to bed until 5AM. Not surprisingly, this morning the stand-up had some people missing in action.
Today is the last day of WeCamp. It means polishing up the projects, preparing the presentation and delivering the presentation. For me it also means sitting down with my team members to evaluate their personal goals for WeCamp. It’s going to be an interesting day.
Logging is an important part of the app development/maintenance cycle. It’s not just about the data you log, but also about how you do it. In this article, we are going to explore the Monolog package and see how it can help us take advantage of our logs.
Monolog is available on Packagist, which means that you can install it via Composer.
composer require 'monolog/monolog:1.13.*'
However, there is a great chance that you’re using a framework for your app. Monolog provides a list of integrations for most popular frameworks. I’m using Silex for this demo, but I won’t be using the provided integration to show how you can configure Monolog for any of your apps.
When you create a new logger, you should give it a channel name. This is how you distinguish your list of loggers. I will bind my logger to the app container.
// app/bootstrap/container.php $logger = new \Monolog\Logger('general'); $app->container->logger = $logger;
Because Monolog is PSR-3, you can be sure that you are adhering to the PHP-FIG standards. This will allow you to switch to any other implementation if you don’t feel comfortable with Monolog (I don’t see any reason why you wouldn’t). You can now start logging using one of the following methods, depending on your log level. (
Continue reading %Logging with Monolog: From Devtools to Slack%
Day 3 brought change. As I mentioned yesterday some of the personal goals that were set during the individual conversations with my team members affected the work we were doing. This meant, for instance, that Jasper took a more leading role within the team, and Kanban was being implemented for a better view on our progress.
There was also some discussion on functionality and focus, as the team members were realizing they were affected by scope creep. So the minimal requirements were defined more strictly and for all the “fluff” extra post-its were added to the Kanban board. The board now also had a split: The top of the board contained all the features that were really needed, and the bottom contained the nice-to-haves. There was even a small corner of the board dedicated to “super-bling”.
The team became more and more of an actual team, with lots of discussions and a lot of pairing and helping eachother. This was great to actually watch and see it happen.
The goal that was set in the morning was to finish the minimum viable product, and the team worked really hard to reach this goal, working until very late in the night. When I left the team at about 11PM they were still at it, and from what I hear they worked until after midnight even. The goal wasn’t fully reached, but we’re close.
Today will be an interesting day, because the MVP needs to be finished, but there’s also the Pragmatist Survival Game and the Enrise BBQ. I’m very much looking forward to seeing what will happen today, and I’ll share with you tomorrow.
Yesterday was day 2 of WeCamp and it was an interesting day. While gathering requirements in day 1 we created two spikes, topics to research to find out if we could actually do what we assumed we could. So in the morning, two people started on the research, while two other team members started on setting up the vagrant box and the Laravel project (we decided to go with Laravel for our project on day 1).
The first bit of research was quickly finished with a successful result, however the second one caused some problems: It turned out we could not do what we had assumed we could do. This meant we had to go back to the drawing board for at least part of the application we’re building.
After a very constructive and successful session we decided that our change in scope wasn’t all that big. We could still build our main scenario in a slightly different way. So we decided on a new list of tasks to focus on and started building those. At the start I noticed that my team members were all working very much as isolated units, but as the day progressed a lot of interaction started happening between team members. This was a nice development.
Another thing I focussed on as a coach was to set personal goals with each team members. So during the afternoon, I had private conversations with each team member to determine what goals they wanted to set. We talked about work, life and ambition and set one or two long-term goals (for “life after WeCamp”) and one short-term goal (“what do I want to have learned/done during WeCamp?”). Some of the short-term goals immediately had an effect on the work we were doing in the team, so we made some changes to the team dynamic to give the people with those goals the opportunity to reach those goals.
We wrapped up the day in a really positive vibe with some excellent progress on our project and went to dinner. After dinner it was time for the Persgroep Gamenight. I pretty much lost track of my team members at that point, each went to play their own choice of games. In my case, this was: Dixit, Exploding Kittens, Masquerade and more Dixit. Being the responsible adults we are here at WeCamp (grin) we turned off the light at 1:30 and went to bed.
As I’m writing this, day 3 has started and the team is already working on the project again. I’ll try to summarize today in another blogpost tomorrow morning.
Listen to the podcast, or watch the hangout video, or read the transcript to learn why the nominated packages were considered to be innovative.
As we just started day 2 of WeCamp I’m reflecting back on the first day of the event. As I am being a coach this year, things are very different from last year for me. I’m hoping to have enough time to publish some notes and obversations every day.
Being a coach
Getting a team of random people to coach is an interesting exercise. First thing to do is to actually try and size up all the team members and see what kind of personalities you have in your team, and how each team member can fulfill a role in the team. Additionally, the skillset of your team members can vary greatly. Although randomly created, my team actually has a pretty nice set of skills, including good frontend skills, good backend skills and even some project management skills. After some initial hesitation, the personalities also seem to be able to work together quite nicely.
Being the coach of this team is an interesting experience. On the one hand, I am here to observe my team members so I can advise them in their further (personal) development as well as help them. On the other hand, especially at the start of the event, I am also looked at to take the lead and guide the team into the project. This is an interesting double role, especially since one requires me to not interfere with things while the other actually requires me to play an active role in the team. Trying to combine those two roles is interesting.
Luckily after some feedback from last years coaches we decided to actually have someone coach the coaches this year. Because of that I am being coached by Jeremy Coates, who is doing an excellent job of giving us some theoretical background information and helping us with the actual practical work. His support in this process is really valuable.
The project has started
After our initial introduction round and brainstorming, we decided on a project to work on. Some really interesting discussions where held on which project to work on, and during the voting the votes were even shifted from one idea to another. We’ve then brainstormed for as many features as we could think, then narrowed our scope to a scenario that we could realistically finish within the time constraints of WeCamp. That scenario was cut up into a set of user stories as well as two spikes, points we needed to research before starting our actual work and this morning, work has started on bootstrapping the project and getting as much information as possible out of the spikes.
Let’s see what we can do today. I’ll let you know tomorrow.