Business researcher and consultant, Jim Collins, used this concept as a metaphor for business in his influential book, “Good to Great.” I’ve been reading about this concept for awhile now and I’ve been trying to apply it in my life and business. My whole life I’ve pushed myself to learn many things to make myself more valuable, now I’m trying to be like the hedgehog and get really good at one thing that can be the numerator for my economic denominator.
The hedgehog principle is a core concept that leads one to a personal path to greatness. A true hedgehog principle arrives as an epiphany and is hiding the intersection of what you’re passionate about, what you can achieve greatness at, and what makes you money. You’ll need to face and deal with the brutal truth around your personal circumstance to find it. You’ll know it when you see it because it will ring true for you, and even taking the first steps towards a proper hedgehog concept will bring obvious results.
In terms of the 5 mountains approach, the hedgehog concept is a boil-down of insight achieved from personal summits in the physical, emotional and mental mountains. The struggles of reaching those summits, or personal limitations teaches one exactly what resources they have to work with because the struggle itself offers insight.
About a month ago, I inherited a “raging dumpster fire” (in the client’s words) written by no less than 10 different programmers over a long span of time in an old, no longer supported version of perl. As a programmer who likes a challenge, I jumped on it and basically put down everything else I was working on to learn mod_perl1.x and Apache 1.x well enough to make them dance. I had never done any real work with perl, and had only perused a hard-copy book on the topic a few years prior in a bookstore, so the initial learning curve for the project was a little steep.
I wanted to dockerize the development environment in a safe way for portability’s sake, so I set to work weeding through github and dockerhub for a working image that used the server tech I needed. I tried several, but the app would not stand up in any of them, some of the errors were incredibly strange. Eventually, I found one that would stand up all of the copious required libraries and got to work learning about and fixing the many broken project dependencies using symlinks to mimic the file system expected and adding tweaking the many, many config files.
During my searching and learning, I spent a some time on IRC. The guys in #perl were actually pretty helpful once you got past their sarcastic exterior. The battle cry of that channel is pretty much “It’s pretty difficult, it would be better for you to just hire my consulting company. If you really want to beat your head against the wall, start reading over there.”
Eventually I got the whole thing up and running and learned enough perl to fix some of the the higher priority bugs and plan new features. Of course I mentioned that we should rebuild the app in a newer technology, but that’s a little ways off.
I recently inheritted a very large project that happened to be written in Django. We set out to have a development environment up for the main site in a week or two.
My first step was to build something in Django. I used this opportunity to create a public boilerplate for django apps in docker. It’s a python django example app (a basic todo), complete with a Dockerfile and docker-compose.yml that builds it. You can read more by visiting the code available in my gitlab here: https://gitlab.jr1.ca/catbadger/django-boilerplate
UPDATE: If you’re going to run django in docker, you’re probably going to want to limit its CPU access with cpulimit and nice/renice. See this article for details
A friend of mine is coming to Ubuntu for his LAMP stack instead of using shared hosting and PLESK. I put together a couple helpful tips for him in chat, and before I knew it, I was over 4000 characters, so I made this post. I hope this is helpful.
* sudo is risky. Be absolutely sure of what you’re about to send to the console as root. I have killed several systems with sudo access and most of them unintentionally (one was a virtual machine on which i was testing a command i did not fully understand.)
* Ask the community. They will help you if you’re polite.
* Learn bash. Learn to use the command line, or one day you’ll need to learn it while you’re risking killing your system. never send anything to the terminal that you haven’t at least looked over or comes from a 100% trusted source (like the official Ubuntu repositories or apt repositories of software publishers you trust) You can start the journey of learning bash by opening a terminal, or logging into your server and typing “man bash” into the console.
* Learn how to read and modify the contents of the /etc/ directory.
* Learn git because you write code, and coding without version control is silly and a huge cause of regression.
* Learn security. Linux is secure by default, but it’s not hard to open yourself up to the whole world (sometimes without even a password).
* For the GUI guys: Learn to search google for software functionality, not software brands. Office is a Microsoft product, but LIbre Office has a great wordprocessor and a spreadsheet program to die for.
The internet is a very noisy place. In today’s social media dominated landscape it can be hard to get your unique and interesting content noticed. I might not have the busiest site on the net, but I do get a few hundred visits a month without guest-blogging. Here are a few ways I use to get my content clicked on:
1. Tweet about your content. Ensure that you participate on twitter by following people with interests relevant to your content. Some will follow you back, and those people will see your tweets. Make sure that you regularily update your followers with links to new content as it is posted. Remember the most successful Twitter accounts are those that make many clever observations about the topic most dear to them.
2. Rock Tumblr. Follow a bunch of people on Tumblr and post links to your content. Ask questions to get a response from your following.
3. Present yourself to Facebook. Maintain your Facebook page consistently and post links to your content. Ask Questions to garner user involvement from your following.
4. Go old-school. Eye-catching posters and flyers in business windows with your content url and/or QRCode are an alright idea. It doesn’t seem to convert well in my experience, but I’m from a small town and I’ve seen some good response to this tactic in bigger cities.
5. Tap into Reddit. Answer a redditor’s question citing your own content as the source. If you use reddit, you likely only consume without posting so that you don’t get in trouble for blogspam. Well if someone is asking a question in https://reddit.com/r/askreddit then your answer has been asked for, and you can usually answer with a post containing a link to your content (as the source of your well-typed answer)
These tips are not the only way to get your content noticed and are meant more to inspire you to find creative ways to use the tools available to you. What do you do to get noticed?
Every time you change code, there’s a very good chance that you will have introduced bugs to your existing code. IT’s important to take a methodical approach to squishing these bugs, or you may waste a lot of time hunting down the cause of specific problems. Here are 7 tips to debugging your code faster.
Don’t pretend that this isn’t your fault (or your teams fault). You wrote the code and you made a mistake. Don’t beat yourself up over it, but don’t blame the computer for your mistake. By that same token, dont’ beat yourself up over a bug. Bugs will always happen, just solve it and move on.
Treat every error as an opportunity to learn about yourself. If you think of bugs as a puzzle or mystery to be solved, you won’t find yourself burning out as fast and this will encourage a more patient and relaxed approach to solving errors.
Write tests. Testing is not only great at preventing bugs but also helps a lot in debugging. Testing forces your design to be more or less modular, which makes isolating and replicating problems simpler. The tighter control this provides over the environment will cause fewer surprises. Moreover, once you get a failing test case, you can be reasonably sure that you’ve caught the real reason of the code’s behaviour..
Use a debugger! Don’t avoid stepping through your code with a debugger just because it’s time consuming. Checking every line of your logic will often help you to find better ways to do things and highlight the real cause of errors. I personally really like the built in debuggers in both Netbeans and PHPStorm
Talk about someone about your problem, even if it’s just a rubber duck (I personally use my android figurines from Android TO). Forcing yourself to express the problem you are working on in words really does miracles.
Give yourself a time limit. If for example after 45 minutes you feel you are going nowhere, just switch to other tasks for some time. When you get back to your bug, you’ll hopefully be able to see other possible solutions that you wouldn’t have have considered before.
As you can see, debugging code isn’t always an exact science,but by applying the right mindset and techniques, you can speed up the process significantly. Fast debugging isn’t always
The versioning tool, git is really useful as it essentially provides unlimited undo for your sourcecode. You’ll likely see git in most roles as a web or software developer. This article is written for new developers who know they need to learn git and not much else about it.
What is Git?
Using Git effectively will be easier for you if you have a concrete definition of what git is. First off forget what you know about other versioning tools. Git stores things differently, and you need to know this to use it properly. The best way to explain this is found in the official git documentation:
Git thinks of its data like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.
The Three States
There are only 3 states of being as far as git is concerned:committed, modified, and staged. Again, the official documentation describes it well:
Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area.
The best way to get good at git is to read the official documentation and follow its examples. You can find git’s official documentation at https://git-scm.com/doc
The factory design pattern solves a common programming problem. When you have a single point of origin for many classes with the same base class, you have need of the factory design pattern. A factory is a class that instantiates one or more of a number of classes that share the same base type, choosing the type of the instantiated object type at runtime without exposing the instantiation logic. You won’t often see this pattern appearing in basic projects, but as you move into enterprise development, it is very common.
In the following example, an object of type ShapeFactory is instantiated by the application code. Then when the getShape() method is called, the ShapeFactory object instantiates a new object which based on the logic in this function chooses which child class of the Shape class will be chosen to hold the new object. This allows a little more freedom in which types we use at runtime.
Factory Design Pattern Example In PHP
The factory design pattern is very simple. The simplest example I like to use to describe it using PHP is a basic game with different kinds of enemy ships. In the following example we will start with an enemy class, and a few child classes that extend it like so:
echo"$name enters going $speed and attacks doing $damage damage";
Now if we are playing a game and wanted to call any of the enemy ship types from a single point of origin, we would spawn them using a factory class that looks something like this:
The code that calls the factory looks like this:
With output looking like this:
small ship enters going10andattacks doing10damage
medium ship enters going15andattacks doing15damage