I was looking through some of my old posts, and started reading one that I wrote for Java, and I just didn’t like it. So, I’ve decided to go through and rewrite a bunch of the old posts (I’ll keep the old ones as they are), updating them to Kotlin. In some, I may even put the old Java code in just to show how much nicer Kotlin makes it.
I’ll try to get the Java/Kotlin version of the DocRaptor article written soon. Also, I’m in talks with another website to write paid posts for their blog. If I get to, I’ll share links to the articles I post there.
I’m also in talks with Apress to write a second edition of my book, Python Descriptors. Changes will mostly be adding content on the
__set_name__() method added to the descriptor protocol in 3.6 as well as a full chapter on my instance–level properties idea. Other than that, I’ll be going through and just cleaning up the writing in general if I spot anything. I’ll probably also simplify the flow charts. At the same time, I’ll be putting together a talk on Python Descriptors that I hope to give at That Conference this year.
Overall, I’m feeling the push to get back to writing. Hopefully, I can keep up with it.
First off, I’d like to thank DocRaptor for sponsoring this article. I’m pretty well off, but this money will be able to help my siblings out, who aren’t so lucky. It also got me to discover their service, which I may find myself using in the future.
What is DocRaptor?
DocRaptor is an online service that can be used to transform HTML documents into PDFs or even Excel documents. This is a paid service, but there’s a 7-day free trial so you can have a chance to try it out first. They have 8 different plans, ranging from 125 documents per month for $15 per month to 100,000 documents for $2250, plus a level for an unlimited number of documents, for which you need to contact them to set up a price. Continue Reading
Some people have spoken against Kotlin’s decision to make classes, methods, etc. public by default (when no visibility modifier is used), and I would just like to pitch in on why I think JetBrains made the right decision on this one. Continue Reading
Sorry, this is late. Excuses, excuses.
I feel like I’ve seen this somewhere else once before in my life, but it the idea doesn’t seem to have spread much. That’s probably due to the lack of traction for pre- and postconditions in general. So, we’ll start with those.
Preconditions and Postconditions
Preconditions and postconditions are a little old-fashioned, having been largely replaced by the proliferation of TDD, but I don’t think they should be completely ruled out. Continue Reading
Some of you who follow me may have noticed a tendency of mine to “hack” programming languages more than really use them (other than reflection via annotations in languages such as Java; I hate that stuff), and today is no different. Today, we look as using what would be normal higher-order functions as Python decorators to create new functions that encapsulate the idea of both the higher-order function as well as the passed-in function under one name. Continue Reading
It’s been a crazy year for me. Loads of excitement and disappointment all around. First off, in July 2016, I lost my job at my first real programming gig due to cutbacks. Luckily, I had saved up about 3 months worth of minimal living expenses, and besides that, I had paid off my credit cards enough to use them for extra cushion. I got a temporary job with Best Buy for about a month starting in mid-late December 2016 until mid January 2017 helping out with delivery and installs of home theater equipment. This was nice, as it got me up to date on what’s available in the market, but it really did not last long. Continue Reading
Man, I’ve had this idea in my head for more than a month now (luckily I wrote it down, too), waiting until the day I wrote this post. I didn’t write it because I was busy with the move and new job, but now things are finally settling down!
Here’s the thing: When you really dig into it, proper object-oriented programming and functional programming are pretty similar. The biggest difference is that object-oriented programming likes to use encapsulation to hide the real data behind facades of objects – requiring you to define methods attached to the type that know about private details – while functional programming is quite up front about it all – making it so that you generally get switch-like structures (but WAY better) that allow you write one function to handle all of the different types. Continue Reading