Tue, 25 Apr 2017 00:33:20 +0000
July US Presented by Chris Hartjes (@grmpyprogrammer) Date: July 20, 2017 Time: 20:00 CDT 18:00 PDT, 3:00 CEST (July 21), 2:00 BST (July 21) Not sure of the time in your area? Check it on timeanddate.com Back when I was learning about how to test PHP code, I had to walk both ways uphill in …
The post What I Learned About Testing While
Walking Uphill Both Ways In The Snow appeared first on Nomad PHP.
Mon, 24 Apr 2017 17:00:13 +0000
John was a developer. To be specific, he was a young, white, straight, young, self-taught developer. He wasn't rare, but he was special. John grew up with a couple parents, who paid for everything he needed. John regularly filled his belly, with the finest food his family could provide. John got every toy he asked for, once he learn that asking for 3 toys was a good way to get at least 1 toy.
John got average grades, but it was ok because [according to mum]; "he's just bored of schooling, and too clever". He walked right out of high-school and into a programming job. The pay wasn't great; only enough for a small apartment and modest groceries [for one]. In time he'd earn more.
Over the years, John quickly got bored of programming. He loved the thought of the career, but it was all so boring. He moved jobs every year or so, and only then when his idiot bosses stopped seeing how much he mattered to their company.
It was just as well, because most of the other developers he worked with were idiots too. Did they even know how to program? All they wanted to do was talk and ask questions and they weren't as interested in John's work as intelligent people should be. He did once work with a girl developer, though. She was so pretty for a programmer. I mean, if you can call CSS and html programming.
I am angry.
For the longest time, I was John. I thought every boring task beneath me, every other developer mediocre at best. I was my own hero, and my mom was right (albeit annoying) that I was brilliant. If only those around me could see this.
Continue reading %How Privileged Are Programmers? Are You a John, Too?%
Sat, 22 Apr 2017 16:00:06 +0000
It's time for our monthly hunt for new open source libraries to use and contribute to!
If you're new to Sourcehunt, it's our monthly post for promoting open source projects that seem interesting or promising and could use help in terms of Github stars or pull requests.
It's our way of giving back - promoting projects that we use (or could use) so that they gain enough exposure to attract a wider audience, a powerful community and, possibly, new contributors or sponsors.
Continue reading %Make Your Own Social Network, Game Server, or Knowledgebase! – Sourcehunt%
Sat, 22 Apr 2017 15:43:48 +0000
July 2017 EU
Paul M. Jones
July 20, 2017
The post Atlas ORM: Doing the Heavy Lifting
For Your Persistence Layer appeared first on Nomad PHP.
Fri, 21 Apr 2017 18:26:57 +0000
In a twisted turn of events, I suddenly find myself to be working for Yelp! It sounds a bit like it was a surprise, and it kind of was. Only 6 months after I started my job at Turnstyle, it got acquired by Yelp.
I would joke “I must have done something right”, but the truth is that I work with some extremely smart and genuine people, who totally earned this.
Working for a much larger company like Yelp will be a huge adventure, and a massive experience to learn from, so I feel really lucky to have jumped on this chance at just the right moment. I can’t wait to build great things with an army of smart people.
And who knows, maybe I’ll get to see a bit more of San Francisco in the future!(image)
Fri, 21 Apr 2017 12:40:07 +0000I recently found myself in a discussion on whether or not exceptions could be used to control program flow in software (specifically in PHP applications). That triggered me to post a tweet: Exceptions should not be used to control expected application flow. Discuss.... @skoop This triggered quite a bit of discussion, which gave me a lot of input on this topic. I want to thank everyone who joined that discussion for their input, which was really valuable. In this blogpost I'll do a summary of the different arguments in the discussion, and give my opinion on this. What is program flow? First of all, what exactly do I mean with program flow and using exceptions to control program flow. The reason for the discussion was an exception thrown in a persistence layer in the situation that there were no results in a findBy* method. This is a slightly different situation from for instance errors with database connections or API connections, things that can be expected but are not meant to be happening. When you do a findBy*, you're effectively searching, meaning 0 results would be a valid situation. This also was reflected in the discussion. @mvriel @skoop @rdohms Find implie Search. Search implies zero results is a valid output. Excepting in a Find-er seems odd to me.Make it a Get-er or wrap in Option @n0x13 This triggered a whole discussion on whether for instance findById is actually searching and whether it would be a valid use case that this would return 0 results. For instance: @n0x13 @skoop @rdohms Finding one item specifically by ID implies that it exists; non-existance is equal to an error 400. @mvriel Why exceptions? A great definition of what an exception is and when it should be using was given by Chris: @thomas_shone @skoop Exceptions are only where the code throwing the exception cannot deal with it. Calling code can always expect the exception and cope! @choult I quite agree with this definition of exceptions. If your code can not deal with a certain situation anymore (such as a missing connection to the database, or an error 500 response from an API) then it should throw an exception. Basically, when something should be there and is not there. In all other situations, your program flow should handle "errors" by itself. What is the intent of your code? I had not really expected this when I first asked the question, but eventually I think the discussion stopped being about exceptions, and started being about naming and intent. Now, we all know there are two things that are extremely hard in software programming: Cache invalidation Naming things Off-by-one errors Let us focus on the middle one: Naming things. Naming things is hard. It is extremely hard. It is so hard people do talks about the subject. But in essence, naming things is easy. Names should be clear, descriptive and describe the intent of the code. Yeah, that sounds easy, but once you start to think of what the right name is, it gets harder. Actually finding the right name is extremely hard. So, let's go back to the example of findById(). Given several tweets in the discussion, different people interpret this method and its intent differently. There's basically two interpretations: find implies search, which means you're going to search for a record with the given ID. When you search, one of the options would be that no results are found ById implies that you're asking for a specific record, because ID is usually a unique key. If you know that key, then the record must exist. If it does not exist, this is an exceptional situation And both interpretations are valid. Which basically means the naming is off. Jaap has a good solution for that: @mvriel @skoop @rdohms Find can return null, getbyid should throw an exception @jvotterdijk I like this idea; when you search (represented in this tweet by find) 0 results is a valid situation, but when you getById() you expect it to be th[...]
Thu, 20 Apr 2017 11:09:22 +0000
Thu, 20 Apr 2017 06:01:55 +0000
Wed, 19 Apr 2017 20:21:55 +0000
I also moved phorkie off sourceforge and host the homepage + downloads on my own server. Sourceforge is dead for me. At first there was the the repackaging-Gimp-with-malware issue in 2015. A couple of days ago I actually wanted to download a file from sourceforge and was shocked how unusable the whole site is, in addition to the memory and CPU hogging advertisements on each page.
Wed, 19 Apr 2017 07:54:53 +0000Usually the problems software needs to solve get more complex over time. As the software itself needs to model this increased complexity it is often necessary to replace entire subsystems with more efficient or flexible solutions. Instead of starting from scratch whenever this happens (often!), a better solution is to refactor the existing code and therefore reducing the risk of losing existing business rules and knowledge. A good strategy for this kind of change is called "Branch By Abstraction". While the term is certainly clumsy and overloaded, the idea itself is genious. Let's see how it works…