foreachorg

[foreachorg]

And there it is: The end result of the Magic Mirror.

Read the full story:

Part I - The Idea & The Mirror

Part II - The Monitor

Part III - The Casing

Part IV - Install The Hardware

Part V - Installing the Raspberry Pi

Part VI - Production of the Interface

[foreachorg]

When you have to pick between security and compatibility

[foreachorg]

When you have too much coffee in the morning.

[foreachorg]

Every so often, I have to adjust some limits where munin starts to scream at us by sending us mail. I just had this issue with a cisco switch that seems to report buggy temperatures. Aside from the fact that I need to deal with this, I just wanted to change the limits so that munin would shut its...

[foreachorg]

[foreachorg]

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Tom Cargill, Bell Labs

[foreachorg]

Launch: The Timely API

We’re super-excited to be launching the Timely API today! It feels like a whole new world is opening with with endless possibilities. Developers can build what they want and integrate Timely into whatever they might need. 

Head on over to the API documentation to learn more. 

We’re also going to start integrating Timely with other apps. Send us the ones you want the most to support@timelyapp.com, and we’ll try to prioritise the most popular ones.

Happy programming! 

[foreachorg]

[foreachorg]

Autobiography of a Software Engineer

[foreachorg]

How do you reason your purchases?

For example: I love Timelyapp. I love it so much that I would like to be a shareholder. I like their approach, I like their execution. I support what they are trying to do and I believe they can, will, and maybe already are very successful at it.

I am not subscribed to Netflix. I am not subscribed to Amazon Prime, HBO, I don't buy things of iTunes, I don't subscribe to Spotify or Grooveshark or any other music service.

I buy books. I subscribed to Timely. And it's such a selfish thing.

A timely subscription costs $14. In New York that's anywhere from 2-3 coffee cups at many fine places like Joe, Brooklyn Roasting Company, myWayCup and many others. My backwater place in the world... the same money would get me about 8 cups of the same stuff.

Is 8 cups of coffee worth it for a glorified replacement for Excel?

For me, yes. Hell yes.

I am unable to fathom the pain of developing at least 4 time trackers, task managers, project management software, ... just to make it easier. Or just to implement what people want, but not necessarily what people need, only to be forgotten, discarded at the way side - for being too complex, too time consuming, too much.

I need Timely. I want timely to be better. I am willing to make something to make Timely better. I am willing to *give* something to make Timely better. It seems to be the deciding reason why I feel good giving money for the service. And that's the difference between Amazon and Timely in my case - I pay Amazon for a flawless service, and I pay Timely to improve, to survive, to flourish.

I hope it will. As for me, I'll drink a bit less coffee.

- Tit Petric

[foreachorg]

Doing some urgent network operations.

[foreachorg]

Mischief is afoot at Tumblr

pipefail is up to something

[foreachorg]

Today, at 9:19 we have gathered to pay our respects and say goodbye to this server, this beacon of hope and stability in our life. The server left us after 2402 days and a little short of 19 hours of uptime. Its death had come quickly, but it leaves us reminiscing of a long period of reliability against all odds.

The server will lie in MMC SR1 until it's disks can be wiped with DBAN and all involved parties will pay their respect. After which it will be scheduled for destruction and ascension into server heaven. You served us well old friend, and with tears in my eyes, I will think of you.

Let me leave you with a short poem:

The Server has crashed! The Server is down! The screens have dimmed in city and town, The emperor stripped of his digital gown, The babbling web is lame and halt, Its pillars of Silicone ground to salt — Default! Default! Default! Default!

When told that the server with 2.5 years uptime was rebooted.

by Tuwi

[foreachorg]

Premature optimization

In my many years as a software developer, this is one phrase which I have heard over and over: "Don't optimize your software prematurely."

I have no idea where the phrase came from. I know that most software is shit because people don't know any better. And generalities like this encourage people to write bad software. I will try to list a few things that I think make up a good developer culture.

Invest in people, not hardware

Developers should be encouraged to think about possible bottlenecks before they happen. Generally, this is called planning, or in some extreme cases, premonition. As long as people are paying attention to detail, the problems will be obvious before they happen.

The thing which I see too often is that a lot of managers throw faster SSD's, more ram, faster and more CPU cores at the problems which shouldn't exist in the first place. This encourages a culture of programmers which think every problem is solvable by more hardware. You wouldn't believe how much running costs we have saved by correctly writing the software in the first place, and then additionally only tweaking the few bottlenecks that were found after the fact, mostly caused by feature creep.

Share your failures

If you make mistakes, learn from them. Define what you did wrong. Admit to your problems and share your failures. If anything, a developer should be comfortable admitting his failures, rather than hiding them. To quote the old adage "The first step to fixing a problem is admitting you have one." and regarding sharing your problems: "Those who cannot remember the past are condemned to repeat it."

Admitting problems shows integrity, which in turn increases trust. Nobody is perfect, it is only how you handle failure that defines you as a person. I'd take the programmer who admits his failures and works on them any day of the week, because I will trust them to say what is and what isn't going well. Sharing the problems with other developers means other people can also learn from their failures.

Specialize

Don't be the guy who knows and does the little bit of everything. While this is fine for individuals and small teams, being specialized is better than being generally good at everything. That's my theory at least.

An expert for SQL only has one problem domain the whole day. Writing SQL queries, preforming DBA tasks. His problem domain becomes his life, he knows how to set indexes and create database structures and squeeze the last bit of performance out of the SQL services.

Now imagine that SQL guy having to work with JavaScript as well. Write some JavaScript, work on some SQL, write more JavaScript. The attention to detail falls by the wayside soon enough, and time is lost in the context switching between the two problem domains.

A specialized developer will solve problems in his own problem domain by a factor faster and better than other developers. I have seen this many times over in projects over the last 10 years, small and large. Specialized programmers however will choke if they have to work on projects that require many skill sets from them. There are not many exceptions to this rule.

Ask for help

You don't need to do everything yourself. Delegate. Figure out what needs doing and what is important. Inevitably there are people around you who are better than you at something. Communicate.

This section could be called team work, but I find it important to get the message to your head that you are an individual. Your skills are your own, and other people have other skills that might be better than yours. You don't need to know and do everything, and don't be afraid to ask for help when you need it. You can search and talk about things outside your company and connect with the local developer community.

In conclusion...

Out of context managers use the phrase "don't optimize prematurely" as another way to say "write code quickly". In practice, performance goals have to be kept in mind, with a balance between design and optimization.

You will inevitably work with some bad programmers or contractors. The "shining light" at the end of this tunnel however is, that the better you are at your craft, the better people you have around you. I've seen good programmers rise out of very unconventional places.

"Cream always rises to the top"

- Tit Petric

[foreachorg]

Outlook 2010 + GMail IMAP

I was loosing my shit over the last few days where I tried to track down an encoding issue in the emails being sent out for a client. The problematic client was Outlook 2010. If the email was sent to the exchange account, the contents were just fine, displaying the special UTF-8 characters. If it was sent to GMail, it was also fine in the browser. But having the account added via IMAP to Outlook 2010 displayed the email contents with garbled special characters in the client (utf-8 encoded characters displayed in a windows-1250 character set).

Somehow, to make this work, you have to send a quoted printable encoded title INCLUDING a special character (Čebela, spoštovani,...). If the title has any special characters, the whole e-mail will display correctly with this combination.

I can only assume that GMail changes the Content-type charset if the e-mail subject line doesn't need any encoding, and wrongly assumes that the content is also latin1/something. Either that, or somehow Outlook + IMAP combination tries to guess what kind of charset the mail is composed in just by looking at the imap mail list, and then again... blammo. Either way, stick a č or something into the subject line and the body will display normally.

Microsoft/Google, I don't care who does it but, please give me two days of my life back.

Thanks.

p.s. moral of the story is that I had a beer at lunch. If I had one yesterday, the problem would already have been solved. Vitamin B or whatever is in there makes you a superhuman coding machine.

- Tit Petrič

[foreachorg]

PHP Comparisons

If there is something every developer (not just PHP) should know, it's when to use a strict equality operator. Interestingly enough, using empty() in PHP has exact behavior as checking loose equality with `== false`.

This whole thing was inspired (and partially ripped off of) the JavaScript Equality Table. The design caught my eye, more than anything. I'm kinda wishing most if not all languages would have this kind of basic reference.

In fact, I find it to be a very useful way to document operators. I'm always kicking myself in the head when I go read some lua code which doesn't use "!=", but uses "~=", and then there's other software where the '~' character doesn't mean negation but regular expression (perl =~, nginx regex locations). It's the little things.

I think that CS knowledge is transferable from one language to the next. If you learn Java or PHP or any other arbitrary languages, you are not locked in to that language - you might have difficulty migrating to C# or LUA or Python, but you can take your logic with you. Your code might not be at the same high standard as your primary language, but it's function will be.

[foreachorg]

It appears that by clicking on one item in the management console, I have locked myself out FOR THE NEXT 10 DAYS!