If you’re like me and have the joy of a keyboard that doesn’t work on your expensive MacBook Pro, and your keyboard insert as many spaces as it feels like at random times. And if you are also a vim user, I have a hack that might help.
I use the following command to find all places with one or more spaces and replace them with a single space. It’s worth noting that in vim, you need to escape things you normally wouldn’t, like the
Also worth noting that I am using the
c modifier so I don’t make changes that I don’t want to.
Yesterday I learned that computer science students do not learn about databases and SQL.
This came up in a conversation about database design and poor SQL execution being the bottle neck in poorly performing software applications, almost all the time.
A recent CS grad said “I guess I should learn SQL.” I laughed. I thought it was a joke. It wasn’t.
As I pried a little deeper, I learned that students didn’t learn about Relational Database Systems either. This means that the next round of developers that pay a gross amount of money to a University to learn how to build software graduate without being taught about foreign keys, primary keys, indexes, database normalization, etc..
But they can analyze various sorting algorithms, which are included in every programming language I’ve ever used. They can also talk theoretically about the speed of certain algorithms.
Analyzing algorithms is really important. But disproportionately favored over really important things for working software developers.
If you’re a CS student. Please take the electives. If you’ve graduated, please invest the time to learn about databases and best practices. It will serve you well.
While learning Elixir there are these little learning moments where the task would be simple in another language, but is a little more complex in a new language and new paradigm.
The task was to create an anonymous function that reacts to the value of the arguments.
From Programming Elixir:
If the first two are zero, return “FizzBuzz.” If the first is zero, return “Fizz.” If the second is zero, return “Buzz.” Otherwise return the third argument.
Seems simple enough, but I was stuck. Based on the examples I had to look back on, I was using the wrong syntax. Those examples used tuples, and I was passing in arguments directly.
Also, anonymous functions and their arguments can be a bit misleading. I thought I would need
fn (a,b,c), but I actually leave that out, and just pattern match for those.
fizzbuzz = fn
(0,0,_) -> "Fizz Buzz"
(0,_,_) -> "Fizz"
(_,_,c) -> c
Then I tried to run it in an iex console. I could load it with
iex fizzbizz.exs, but couldn’t call the function. Nothing worked.
I just decided to run it with elixir directly and print out the result of calling the function within the file.
There are software developers that love to start projects. Especially in the Rails ecosystem. And for good reason. It’s easy. It’s fun. It’s low risk and high reward. There isn’t any technical debt. And they look like a superhero. Business people love them. Just look at all the work that was done in such a short amount of time. What’s not to love?
Of course, we know that this is because of a clean slate. It’s easy to make amazing progress when there isn’t anything in your way.
Build up some technical debt. Add the need to stop and think about breaking the app. And the velocity and superheroism starts to fade.
I’ve spent the majority of my career coming in post-superhero. It’s no where near as glorious as the fresh start, but multitudes more important and difficult. In my opinion, this is where the term engineer fits a little better.
There is a lot to think about at this stage. Maintain existing functionality while extending the application to new ground. And debt must be paid here.
A developer will often be compared to the previous developer that seemed so fast. Clearly the previous developer must have been smarter, better. Probably one of those 10x developers we hear about.
Oliver Eidel has written a really good article comparing pioneers and process people. Where pioneers are the developers that can throw caution to the wind, move fast, and make something great. And process people come in behind them and stick to processes.
What I got from the article is that these two roles are distinctly different. I agree. And that once an app hits the process phase, it’s time for the pioneer to move on to build something else. I disagree.
The best developers I know are a hybrid. Builder when needed. (Everyone loves to hack a solution together.) And a more thoughtful engineer when needed.
These are two different roles, but you are far more valuable to your team and your company if you can do both.
Yesterday as I was working on some Elixir code, I discovered something that wasn’t obvious to me before. If you have a function that takes an argument, you can leave the argument out if you piping functions.
In retrospect it makes sense. When you pipe functions in Elixir, the data being piped in becomes the first argument.
IO.inspect and Enum.reject are the examples that I was working with.
IO.inspect has two variations. One with two arguments and one with three arguments. I’m just using the one with two arguments. The functions signature is this:
inspect(item, opts \ )
So, assuming I have some variables called coll, I can inspect that with
IO.inspect(coll). The opts I always uses is label, so I can find it easily in the log.
IO.inspect(coll, label: "Debug Collection")
But if I am piping my coll variable through a series of calls, I can leave out all arguments because opts is optional.
Previously, I was inserting the inspect call where I could to see what was there. This is just one of things that I didn’t expect and was not obvious to me, coming from an OOP background.
I only discovered this when I needed to get rid of some
nils in an
Enum type. I could not figure out how to skip
nils. I could use
Emun.reject(enumerable, fun), but I could only use it in the middle of a series of pipes. And I didn’t know what the variable would be, or how to use it. Turns out you don’t need it. Same style works perfectly.
Sometimes you need to disable your testing tools in order to know what you’re testing. Mocking and stubbing are great. But only when you know what you are dealing with.
If you have VCR installed and configured in your Ruby app, and need to disable to make real requests until you know your code works, add the following lines.
Of course, make sure you take these lines out once you’re done.
Working with some systems that have some self signed SSL certs for working in staging/sandbox environments and needed to test out some URLs. Naturally grabbed
curl, but was getting an error.
curl: (51) SSL: no alternative certificate subject name matches target host name
Turns out the fix is easy. Just pass in the
curl --insecure https://domain.com
I’ve always seen
127.0.0.1 as the same thing. It’s definitely the same location. But I hadn’t considered that it may be seen as a different host. In fact, I’m still not sure if it is, or even if it should be.
I’ve spent a couple of days debugging some weird issues with Ory Hydra. Let’s set aside the fact that it uses OAuth2, but what seems to be in an unconventional way. I need to make about six
http requests to get a token. I don’t know if that’s normal for an identity provider, but it seems excessive.
The issue I ran into was within those six calls,
127.0.0.1 had gotten used interchangeably. I received various error messages. Everything from telling me the
error is indistinguishable to errors about an unknown client, or errors about
While googling the error messages over and over, just looking for a sliver of hope, I saw a comment that fixed everything.
Turns out Hydra sees
127.0.0.1 as different hosts, but doesn’t complain about an unknown host. That might have led me down the right path sooner. And I never use
127.0.0.1, so I’m pretty sure that was a config setting when I was using the 5 minute tutorial to set everything up.
Make sure to check what host you are passing around when setting up
I had an idea. I asked myself if I could create some sort of mini-course and sell it. Something super simple. Something like working with CSV files. The answer is no. But not only did it fail, it failed big time. Not one sale. Nothing.
So what went wrong? I have a few ideas.
- I was trying to sell a solution to something that was free all over the Internet. Seriously. Google “CSV Rails”. There is A LOT.
- It wasn’t really a solution. Watch me write code to import data from a CSV file is not a solution. It could be entertainment, I suppose.
- I assumed that because I was successful teaching in person, that I could do the same on the Internet and people would just know that I’m good at it. This is false.
Those reasons should be enough to scare anyone away, but I tried anyway. Now I just need to make sure I don’t make the same mistake twice.
For my next experiment, I’m going to try more audience/product validation. That seems like a better start.
Intentionally omitting documentation because you think someone should use a library might seem like a good idea. I mean we should use tools that are available to us. But when a developer needs to do something a little less conventional, it makes it really difficult to use your library.
I’m currently working on something with the oauth2 specification. And because reasons, we are implementing our own identity provider. We are still working within the parameters of the spec, we are just doing some authorization a little differently.
The library that we are using for our authorization server refuses to show all of the parameters needed to build urls for oauth2. The reason being you should not code this yourself and use a library instead. I agree. But sometimes, you need to build some things yourself. The fact that this library tells developers that they are not responsible enough to implement parts of the oauth2 spec themselves is short sighted to put in nicely.
A better approach might have been something like we strongly discourage you from implementing parts of the oauth2 spec yourself. There are plenty of really good libraries that can do this for you. Please consider one of those. But if you have to, here is the documentation you need
Let the developer decide.