Mittwoch, 23. Oktober 2013

Getting speakers for your Usergroup

Are you organizing a Usergroup? That's awesome! But you might share the problem of not having enough speakers and not having cool topics everybody wants to hear about. I myself was (and still am) in this situation with the very young ViennaPHP Usergroup. Let me tell you how I partially managed to solve this problem.

The organizers mindset

You might be struggling to get speakers because you as an organizer are not commited enough. Its a hard reality that a usergroup is much work and just putting an announcement on meetup and waiting for talks to come in will hardly do it. You need to market your group, get cool locations and sponsors and engage with your members.

If you do this, people will recognize that there is something happening and will jump in to help. Of course this requires up front work on your side, but that's the way it is

Don't just ask the group, ask the persons

Sometimes I see emails from Usergroups with "Who wants to do a talk?". I'm usually eager to talk, but this emails won't make me do a talk. They are just noise in my mailbox. If you want me to do a talk, you either have to get my interest by organizing a great usergroup I want to participate in or you ask me directly, already knowing what I usually do and suggesting topics and everything.

It's the same with most people. I was writing an email for every meeting, trying to get speakers. Nothing happened. Now I'm approaching people at our meetup, other meetups or through email and ask them "Hey, you are great at X, would you mind talking about it a little?". This makes a big difference!

Ask strangers

If you would have told me that just emailing a bunch of people would get our usergroup 2 international speakers within a month, I maybe would have used the word "crazy" to describe you. But it works. I used a combination of contacts (from former jobs, meetups, conferences) as well as "cold-call" emails like "Hey, I know you do X, maybe you are in Vienna to do a talk?" and even send emails to companies saying "I love your product, would you happen to know somebody in Vienna who would like to do a talk about it?".

The replies where about 10% and up until now only 2 speakers (which is about 5%) are confirmed, but that's huge for my terms! I have another 80 email addresses on my list and if the percentes keep up, this means 4 other speakers for 2014!

Just do it!

I guess doing it is the hard part. Writing emails to total strangers asking them for help is not something I do every day. But the feedback I got was positive all the way. People where apologizing for not having a speaker at hand or saying they'd love to join us anytime soon if they happen to be around Vienna.

By writing all these emails, the ViennaPHP Usergroup has both David Mytton (CEO ServerDensity) and Freerich Bäthge (CTO Sensiolabs Germany) speaking at the November Meetup. And that's worth the hassle!

Montag, 7. Oktober 2013

Join the ViennaPHP Meetup at October 10th!

If you are in Vienna at October 10th, you should definitly check out the ViennaPHP Usergroup! We have set up a very cool meeting with some cool talks at a very new Coworking location and also got your drinks covered: http://www.meetup.com/viennaphp/events/141809032/

Beside me doing a mini-mini-talk on composer titled "Composer in 2 minutes" (which will tell you nothing you don't already know if you are familiar with composer but might wake your interest if not) we have Michael Klobutschar and Klaus Purer, organizers of the DrupalCamp Vienna 2013, who will talk about "Developing with Drupal". We also got Stefan Hupe who will do a small talk about " Debug messages and logging with monolog".

We were able to find some sponsors, which means free drinks and some nice surprises for everyone. We would like to gather more than 20 people and this seems reasonable looking at the RSVPs.

Hope to see you there!

Dienstag, 7. Mai 2013

ViennaPHP Kickoff: 15.05.2013

I am proud to announce that I am the new organisator of the PHP Usergroup Vienna. I am taking the place of Michael Nitschinger, who organized the first drinkup last year. I hope to establish a regular meetup once a month with varying talks, nice people and interesting discussions.

Our first meetup will take place on 15th of May, 2013, at Metalab. The meeting will be held together with the symfony Usergroup and the Web Performance Usergroup and the first talk will be "assetics" held by myself. Of course everybody is invited to do talks (various length, mini-talks). If you have an interesting project, work with interesting technology or have some story to share, go ahead and hit me up.

You can find the group on meetup, get informations about the next meetups and RSVP. There is also a website at viennaphp.org, which is not up to date. I am trying to get the new content up and it should be finished soon.

After this general information, I would like to get into a few details.

Sonntag, 5. Mai 2013

In search for (CD) collectors!

I love my collection of CDs. I cannot count the times I tried a piece of software which stated to help me organize it. The software was either way to complex (I don't feel the need to save each track of each CD), not flexible enough (I would like to have some additional fields - Not only text, but also selects, checkboxes and so on) or simple crap.

And because this is of real importance for me, I am starting to build a CD collection "organizer". I don't know what direction I will take or where I'll end up, but I'm sure it'll be a very good tool. I actually started developing this a few times, but without a clear goal and everything, each of the implementation either ended up as not satisfying or didn't get to the point where it was usable.

Instead of diving into code, I'd like to do it the right way this time, first making a (short-term) plan and some ideas on how it will look like in the end, then start coding. For this to happen, I would like to talk to some people who are collecting CDs (or maybe DVDs or books) themself and who feel the pain of collector software

If you happen to be one of them and could spare 10 minutes for a skype call/email conversation, ping me either here in the comments or on twitter. Or maybe you are happy with some piece of software you are using? That would be also very interesting to hear about! It doesn't matter if you only throw me the name of the tool you are using or take some time to talk to me more in-depth about what you like or doesn't like about your tool.

Anyway, you'd help me a lot and maybe we end up building the best collector app out there together!

I'll of course keep you updated on what is happening regarding this project. I don't expect it to take of for a few more weeks, because as said, I want to do some ahead planning and thinking about what is really needed.

Freitag, 5. April 2013

OSS documentation: Thoughts about the Symfony Docs Hack Day

Last Saturday was Symfony Docs Hack Day, and I think it was very successfull. Both WouterJ and weaverryan worked hard to provide information to everyone in need and were well prepared. The workflow was very nice, the Google Docs document was exactly the information everyone needed. Many issues got attention, many PRs got created and there are already some which are merged. The attitude was supportive, the chats really nice. Everyone cheered about PRs and had a good time (at least as far as I can say).

If you want some statistics about the Hack Day or want to see a list of pull requests and contributors, head over to the symfony blog. I'll focus on what this Hack Day really means for the framework and the community.

Normally, hackdays happen to improve the code. And that's ok and a good way to work on a project. But the documentation is nearly as important as the code. Without good documentation, the best framework or library will be unusable. There are many projects out there which might be awesome but due to the lack of documentation are never adopted. Developers might try it once, but as they don't understand how it works, abandon it pretty soon.

The symfony docs always have been a very good source to understand the framework. symfony 1 had a nice "jobeet tutorial", telling the internals by creating an example project in 24 days. symfony 2 started with a good documentation called "book" and advanced cookbooks. symfony always took care that the docs are up-to-date and worked on making the docs nice to look at. Due to this effort, there are now many people caring about the documentation in much the same way as others care about the code.

I believe this attitude has built an environment in which people work hard to do a hackday on the documentation. It's an environment in which many people join this hackday to make the documentation better. It's an environment which will make the framework itself better.

Creating such and environment is pretty hard. If you don't think of docs as one of your core features, you will most likely fail. If you "just write something so people can use it", there won't be many people to make it nice. The initial effort is big, and if you look at symfony, I guess they learned a lot from the first version. You also need the people who developed to write some of the initial doc. Looking at the Contributors Graph you can see that Fabien did most of the initial work. Others took over so he could focus on managing (or coding, I don't know), but in the beginning much of the docs were written by him.

And if you want people to contribute, it must be easy. Sphinx, the docs framework used by symfony, is not the easiest but it does the job. But if installed correctly, you can create the docs with one command and have a look at the plain html. The layout is different, but the features are there and you can check if anything is broken. Making it difficult to create the html locally means making it difficult to make good pull requests. Some guidelines also help.

All this combined has lead to a awesome documentation, both for beginners and advanced users. It's a joy to read and most likely helps with all issues at hand. Thanks to fabpot, weaverryan, WouterJ, stof and all the other who contributed, both on the hackday and in the past!

Freitag, 29. März 2013

Things every developer should do at least once

There are things ever man/woman should do at least once. Here is a list of things I think (mind you, it's just my point of view) every developer should do:
  • Contribute to an OS project: I could write a whole page why I think every developer should contribute to opn source and just going on and on about that it is the only responsible thing to do. Instead I want to focus on the positiv: It makes you a better developer. Looking into other people code, diving into the whole concept of this project, then trying to fix a bug/implement a feature and get feedback on it is very valuable.
  • Learn a functional language: I'm not talking about learning it in depth and every aspect of it. Just choose one, look into it and get used to it. You don't need to use it often, but looking into it you will give you another perspective. You will see another way of doing things. It will make some implementions much nicer, even if you are coding strictly object oriented (Immutable objects for example are a concept worth looking into).
  • Look into shell scripting: There are small things where it's much nicer to get some shell script up and running than integrate it into your application. If you don't know shell, you don't know when this applies. Since I know a bit about shell scripting, I see opportunities.
  • Experience Test Driven Development: Knowing what this exactly is and how to do it may help you. You may not use it every day (even if I would suggest it!), but again you may learn valuable lessons. It's also not about saying the way you are currently developing is bad. It's just about seeing things from another angle.
  • Set up/Maintain a server: Again, I'm not talking about production server, critical systems and in depth knowledge. Just dive into system administration and see what "the guys at IT" are doing all day long. Learn their problems and you may understand why certain things are done in a certain way. The idea of DevOps (bringing together developers and operation guys) is really appealing, as it solves those communication gaps and may lead to a healthier, more supportive environment to work in.
  • Educate yourself: Waiting or your company to push you into a language/framework/tool is something that isn't going to happen. Thinking you know it all is a lie. The only thing you can do is stay on top of the news and just look into new things briefly. For web developers, there is much going on with javascript MVC frameworks right now. There is also much HTML5/CSS3 stuff happening. NoSQL might be something every developer who needs to store data on a server might to want to look into.
This list isn't complete. And I think it's not the point to make a complete list. The point is to acknowledge that you should do something. There are so many ways and opportunities to get better and evolve. You just need to start.

    Dienstag, 19. März 2013

    Using screen(1)

    Sometimes when it comes to sysadmin stuff, I don't have all the tools at hand or don't even know about them properly. I am not a sysadmin but have to do some stuff on our servers and one tool which I use more and more is screen.

    I read about it at webadvent in a post by Remy Sharp and had many situations this could be handy. One where long-running commands. I was using nohup which was ok but had a few drawbacks. I could not do anything else while the command run. I also need to remember to put nohup in front of every command which would maybe run a little longer. Now using screen, I'm inside a "standard" session and if my connection cripples, I can get back where I left of in no time.

    Another use case is a very basic deamon. If you run any command in screen, you can exit the screen session and the command will continue to run if the program is not at the end. I would not recommend running apache inside a screen session in production, but if you have something non-critical, you could use screen. I did it yesterday to run a command which logs i/o data. I wanted to run it for 24h and just startet it inside screen. Nice! I also use it sometimes if I need to run a python or node.js server in my development environment and don't want to block my ssh session (I ssh into a vagrant environment).

    And if you are working remote, sharing a session and being able to work together on a problem is also an awesome feature. It makes working together on a server easy. It is also easy to leave the problem and let another person return, as he can take over, see what was done and has some kind of history other than the bash history which may include commands not related to the problem and often has to little information.

    I think what amazes me most about screen is that it's a tool that does one thing, and it does it good. It does not want to be the only tool you need but is a tiny little thing, always there when you need it. If you want to try it check the blog post mentioned above or one of the many tutorials out there. It's very easy to use because of it's simple nature and brings real benefit.

    Mittwoch, 13. Februar 2013

    Remote Working #1: Primer

    I'll start remote working soon and I thought about starting a series on this topic for a while. This series will be a mixture between a diary and tips/lessons learned. It will evolve with my experience and may change over time.

    So, let's get a little context into this. I Co-founded PicturePlix two years ago and it was clear that I would leave Munich in 2013. We all agreed that this was a topic we would dicuss when the 2013 arrives and we did. We decided to try remote working without much experience in this field. We don't know the parameters yet, but the idea is to work from Vienna, my new home, and visit Munich once a month for two or three days. There is no timezone difference and 400km in between, so the distance is not that big and we will not face timezone problems.

    My setup in the new flat is a 10qm² office all to myself, currently loaded with all the stuff which is not sorted out yet. I'll have 100 MBit internet through tv cable and a power lan to get the signal from the living room to the office. I already heared from different people that power lan might not be so great but will test it nonetheless and see how it works out.

    My overall idea is to work as closely to a "normal" workplace as possible, meaning I'll eat breakfast, dress and do everything as normal and then instead of commuting I'll step into my office. I'll have lunch with my family but will keep the interaction with them through the day as minimal as possible, especially in the beginning.

    In my opinion this is essential because we are all not used to me working at home over a long period and need to adjust. It makes things easier to have clear rules to get a feeling. If everything is working out great, I have no problem with an interuption once in a while because of something important (as a matter of fact, I get private calls at work which is somewhat the same).

    For my office I think about getting a standing desk. I have some stuff saved from our old flat and will try to build one similar to the one Colin built. I don't know how I will be using it because I would like to sit and stand equally, not standing all day. Maybe I'll use two monitors at different parts of my desk with two keyboards so I can just move my laptop if I want to stand up (or sit down).

    I'll add a whiteboard for sure and I think about getting one or two posters from Busy Building Things. I don't know about my technical setup right now I guess I'll just see what I need and iterate till I have a freaking awesome office. I am already thinking about music, maybe a file server (Rasperry Pi anyone?) and much other stuff which could be a nice feature. But these are all nice-to-have things.

    For now I'll focus on getting an environment where I can focus on my work. Because that's what an office is for!

    Next time I'll write about the first week. What worked, what didn't.

    Montag, 14. Januar 2013

    Please, don't replace your dashboard!

    On HackerNews there was an article talking about analytics dashboards and how they should be streams instead of charts: All Dashboards Should be Feeds by Anil Dash. And even if I can see how a stream can be appealing when you look at it, I strongly disagree that streams will solve any problem at all.

    The article states that every dashboard should be transformed into a stream, which shows text messages with recent and upcoming "events" (like hitting a certain number of followers on twitter). Instead of showing a chart, the feed will extrapolate your followers and tell you that you hit X followers in a week.

    First of all, I highly doubt there is a problem with dashboards as they are. If somebody cannot get data out of the dashboard, it's simply configured wrong (or isn't configurable, in which case I wouldn't call it dashboard) or he doesn't know what he's looking for. If I open my Google Analytics, my dashboard shows me the visitors per day, from where the traffic is coming and which countries the traffic is from. That's all I need, and the charts are exactly the format I need it. If I have special questions I need to answer, I can dig into this using the the other, more detailed views. If I just want a quick update, I can look at my dashboard and in a second see whats going on. I hardly see how a stream could tell me all this at a glance.

    I imagine logging into Google Analytics and seeing my stream with messages like "A new referer xyz.de brought you 250 visits", "You will hit 10.000 pageviews tomorrow" and "Mobile visitors are down 10% this week" while all I wanted to know is how many page views I had daily the last 30 days. If I need any of the information from that stream, I can configure my dashboard to show it to me or dive into analytics and figure them out myself.

    Thinkup, the startup Anil is involved, has a demo on how a stream like this could look like for a twitter account. This is interesting, but it's neither a comprehensive overview nor something actionable. I see someone retweeted a post and this someone had 50 times more followers than the account in questions. Now what? And if I came to see on how many retweets I got the last 30 days or which tweet was retweeted the most, I would have to dive into analytics (I don't know if this is possible or will be possible) to find out. A nice little table showing the top retweeted posts would be better!

    Another thing in the article is the mention of "suggestions" inside the stream. I don't see any advantages to a dedicated section where suggestions are shown as part of a dashboard. Buried inside a stream they are hard to find. You would have to write down each suggestion somewhere if you are not ready to act on it right now because else it's lost. It also clutters your stream with information you don't want or need right now.

    Overall, I don't think streams are a replacement for dashboards. Maybe it works if Users don't need a real analytics tool but woudl like more of an information tool where they can have a look while I relax a bit and see how my followers are doing. It certainly doesn't work for the use cases dashboards where made for! So please, don't replace the dashboards. But maybe add a stream as another option, so people can choose

    Donnerstag, 10. Januar 2013

    Screw productivity

    Their, I said it! Measuring productivity, even thinking about how productive something orr someone is, is a waste of time. At least in my opinion.

    First, let me dive into the reason I started thinking about productivity. I somehow discovered RescueTime, a productivity measurement tool which analyzes the programs you are using on your PC and making reports outt of it. You can then see how productive you are, at which times you are more productive or how you compare to yourself last week or to all the other users.

    I tried it, spent some time configuring it and then waited to get the first meaningfull results. I ended up being 70% productive, which is nice considering I'm using my laptop for both business and private means almost every day.

    But I soon realized that the measurements where somehow not relating to my feeling of how productive I was. The reason is very simple: There is no way to tell if I'm productive if I use software X or browse website Y. Let's say I'm on facebook: I could do random stuff and be 0 % productive or write someone a message which is related to work and being 100% productive. It's even hard for me to put a number on my productivity in many cases. Consider me installing some tool to play around a bit. It could be just for fun but the knowledge could be useful for me 1 week later. Or it could turn out useless because the software is crap. But even then, if I never try new software, I'll never find the usefull ones either.

    My last point is the real problem with productivity for many jobs. You will always do stuff which will not be productive in a direct way but an indirect one. Let's pick a real-world example: I knew a very good hair stylist. What does it meant for her to be productive? Wash the hair, cut it, dry it? Well, of course, but also to create a nice atmosphere for the client. The output is not a haircut, but a happy customer with a haircut that looks well! And if she takes 15 minutes "off" to help a co-worker get in a better mood and this co-worker happens to make the customers more happy partly because of this, wasn't her "break" productive as well?

    As a member of a start-up team, my job is not to write code. Yeah, ok, it's part of my job, but not the most important one. I also have to do system administration, project-management, human resources, administration. And on all of this I don't have one specific role, but all roles possible. I don't only have to write our apps, I also have to research new technology, think about system architecture, testing, quality, deployment. I not only maintain our servers, I research IT topics, improve our current servers or check them for security or stability. I'm not only responsible for finding new talent, but also to make the team happy. Of course all the other members are responsible for all this too, but that doesn't mean I don't have to know about all this stuff.

    Thinking about this, if I read an article about a new Ruby framework, am I productive? We are not using Ruby now, but maybe we want to in the future. Maybe someone applied to use who has a ruby background? And even if all this is not true, is it not part of my job to know about the frameworks out there to be able to make proper decisions? It happens very often that I use things I create in my free time at work and the other way round. I play with a framework, some tool or simply create something, and later I come up with a solution for a problem which just popped up because of this knowledge.

    I guess it all comes down to what is the expected output. And for the most (if not all) jobs you cannot really define the output and all the different things it gets influenced by. I mean hell, even if I play a game of Sudoku for 15 minutes but get back to work refreshed and faster it has made me more productive overall. So, for me it's not about productivity anymore.