programmers tools

Chef notes

Sometime back I had to fiddle with Chef. I created some notes, posting it over here, so that I won’t loose it. Don’t think it’ll be useful much to anyone else other than me ūüôā Its basically a list of instructions that is scattered on their site.

So, anyone other than me, please ignore this post!

Write a cookbook
chef generate repo ~/chef-repo
=> Install starter kit to create .chef directory and certs that we need to communicate with chef server
cd ~/chef-repo
chef generate cookbook cookbooks/COOKBOOK_NAME

Create a recipe:
chef generate recipe cookbooks/COOKBOOK_NAME RECIPE_NAME ## RECIPE_NAME shouldn’t have suffix. Eg. it should be ‘webserver and not ‘webserver.rb’
=> Write the script in RECIPE_NAME.rb file that got generated

How to refer(include) a recipe(RECIPE_NAME) in another recipe:
include_recipe 'COOKBOOK_NAME::RECIPE_NAME' ## Eg: include_recipe 'my_cookbook::webserver'

## By default the recipe that gets called is ‘cookbooks/COOKBOOK_NAME/recipes/default.rb’
## So include any other recipe in this using include_recipe

Create a file:
chef generate file cookbooks/COOKBOOK_NAME FILE_NAME.txt

How to upload the cookbook to the chef server. There are 2 ways:
## Option 1. Prefer this one. This one takes up the dependencies if any.
## Create a file named Berksfile in the ~/chef-repo/cookbooks/COOKBOOK_NAME directory
## Add the following to that file:
source "https://supermarket.chef.io"
metadata
## Install the dependencies:
berks install
## Finally upload (along with dependencies):
berks upload ## OR without SSL => berks upload --no-ssl-verify
## Option 2. This one just uploads the cookbook. Won’t download dependencies
knife cookbook upload COOKBOOK_NAME

View uploaded cookbooks:
knife cookbook list

Bootstraping the node
knife ssl fetch ##Save the SSL certificate
knife bootstrap IP_ADDRESS_OF_NODE -x ROOT_USER_NAME -P ROOT_PASSWORD --sudo ##BOOTSTRAP!!
## Verify bootstrap process was successful. Either check in chef manage console or do:
## On Windows
knife node list | findstr NODE_NAME_WINDOWS
## On Linux
knife node list | grep NODE_NAME_WINDOWS

How to reference another cookbook:
## Append following to ~/chef-repo/cookbooks/COOKBOOK_NAME/metadata.rb:
depends 'ANOTHER_COOKBOOK_NAME', '~> MAJOR.MINOR.PATCH' ## Eg: depends 'sql_server', '~> 2.4.0'

How to override third party cookbook’s attributes:
## Create a custom attribute file that overrides third party attribute values:
chef generate attribute cookbooks/COOKBOOK_NAME default
## Add override values as follows in the generated ‘cookbooks/COOKBOOK_NAME/attributes/default.rb‘:
default['ANOTHER_COOKBOOK_NAME']['ATTRIBUTE_NAME'] = ATTRIBUTE_VALUE
## Eg: default['sql_server']['accept_eula'] = true
## Eg: default['sql_server']['version'] = '2012'
## Eg: default['sql_server']['instance_name'] = 'MSSQLSERVER'

Modifying cookbook version:
## Edit ~/chef-repo/cookbooks/COOKBOOK_NAME/metadata.rb to change the version

Applying cookbook on node:
## Run the following directly on the NODE, (NOT ON THE workstation):
chef-client

My Developer Personality

I took a¬†Developer Personality Test, conducted by DZone and it almost sums up what I am! Here’s the result I got:


Here are your results!

Independent vs Collaborative

You are Independent!

Independent:
You prefer to spend most of your time working in an isolated environment.¬† You rarely want to collaborate because you have a better chance of solving problems on your own.¬† If you do have to collaborate on the direction of a project, you dislike it when you have to defend your position or when others try to muddy your plans for the project.¬† It’s better to have one strong vision for a project from the lead programmer on that project.¬† Having a large team or allowing others to have significant control over the project risks communication errors, a muddied code base, and inefficiencies.¬† If one developer has a firm grasp on the entire codebase, they’ll be much better at fixing and improving it quickly.

Collaborative:
Good code doesn’t happen in a vacuum.¬† You need a team to keep you energized and on your toes so that you’re constantly improving the project code using the entire team’s varied experience and strengths.¬† You like to talk frequently with colleagues and discuss ideas so that you can learn from others and spark ideas.¬† It doesn’t matter what their experience level is, you can always learn something by including everyone.¬† A solo coder can’t possibly code a large software project with the speed and quality that a team can.

Abstract vs Low-Level

You are both Abstract & Low-Level!

Abstract:
You prefer to write in languages and frameworks that simplify development as much as possible and use as few characters and lines of code as possible. The trajectory of software development has always been toward making life easier and error-free. Programming has always been about adding more abstraction layers to simplify tasks, so why not trust the technology on your layer and don’t worry about handling the lower layers?

Low-Level:
The more abstraction tools and high-level languages we build, the further we get from understanding and controlling the deeper components in our programs.  This means lower performance and endless bug searches.  Developers today need to have a stronger understanding of compilers, memory management, pointer arithmetic, and other low-level topics.

Frontier vs Conservative

You are Conservative!

Frontiers:
You like to work at the cutting edge.¬† Using too many old languages and technologies bores you, and it severely hinders your software’s potential to keep outdated technologies in it for too long.¬†Developers need keep their ears to the ground for new technologies and new versions of tools that they already use.¬† Even if the community and maturity of the project isn’t at a level that most enterprises would consider “safe,” you’re willing to be an early adopter if you believe the community and the technology has momentum.¬† Development technology is changing faster every day, and we need to constantly be adopting new tools and methods to keep up.

Conservative:
It seems like every 10 years we forget all the problems we solved in the previous decade and start to build ‘new’ tools that solve the same problems, even though there is a perfectly good solution that has existed for years.¬† Enterprises have it right when they make conservative decisions about their technology stack. Why would you hang your business on a technology with only a few years of maturity in just a handful of production use cases?¬† Technologies like PHP, Java, and SQL have been mainstays of the development industry for years, and it takes a lot of time for new technologies to make it into that maturity tier.

Generalist vs Specialist

You are both a Generalist & a Specialist!

Generalist:
You like to be known as a “Jack of all Trades” and a reference for others on your team. You jump at every chance to enhance your skills in a wide variety technology topics, not just the ones that apply to your day to day work.¬† You don’t always know when it might be useful to have these extra skills, but when the time comes, you are ready.¬† If more developers took the time to learn other skills outside of the ones relevant to their project, they’d work more seamlessly with the rest of their organization because they’d have more empathy and understanding of the challenges that their colleagues face.

Specialist:
If you’re a Jack of all Trades, you’re a master of none. Mastery in one or two areas is what makes you valuable.¬† What’s the point of learning skills for other jobs you don’t have and can’t control? When you plan for a project or do technical research, it’s always focused on something you’re working on. You don’t get side-tracked. If you learn a new skill, it’s because the project requires that you do it. Most or all of your hobby projects are also building your mastery of the skills you use at your job.

Idealist vs Pragmatist

You are an Idealist!

Idealist:
You believe in the power of well-defined processes. It’s crucial to an organization’s success that they create and follow appropriate and effective processes for building software. Trying to improvise or play it by ear invites the possibility of workflow errors that can decrease the quality of the software or even cause major product failures. Planning is also extremely important to you.¬† You like to research all of the things you will need to know before starting a project.¬† It’s important to find out the best architecture for your software beforehand, and then strictly implement that architecture with objective best practices.¬† The more planning and scaffolding you do in the beginning, the less overall work you will have to do to complete the software.

Pragmatist:
Speed is your best weapon in a competitive industry, and to quickly prototype and build new products, you need to have a flexible, pragmatic process.¬† You don’t have a few months to plan your projects, you need to just start coding and a good path for the project will reveal itself.¬† Great products are made through frequent feedback and releases, so why shouldn’t your plan be just as adaptable? Your plan should be adapted to changes in the software, and your expertise should be adapted to the project. You shouldn’t spend your precious time studying a problem that you’re not certain to run into while coding your projects.¬† Trying to build test coverage for every possible scenario and having long meetings throughout the process are a waste of time and distract you from doing more productive work.

Imperative vs Declarative

I was watching an AngularJS video, and it said AngularJS had two sides РImperative and Declarative programming. I looked it up and here it is :

Let’s generalize and say that there are two ways in which we can write code: imperative and declarative.

We could define the difference as follows:

  • Imperative programming: telling the “machine”¬†how¬†to do something, and as a result¬†what¬†you want to happen will happen.
  • Declarative programming: telling the “machine”1¬†what¬†you would like to happen, and let the computer figure out¬†how¬†to do it.

1 Computer/database/programming language/etc

 

My Git Workflow

Clone repository to local machine: git clone <repository>

  1. git pull
  2. code… code …. code…
  3. code more…..
  4. git stash
  5. git pull
  6. git stash apply
  7. git add <filenames>
  8. git commit -m “commit message”
  9. git push

If any conflict occurs when stash is applied, resolve it either in IDE or using command line: git mergetool -t kdiff3 (invokes KDiff 3 if it installed)

Happy Coding ūüôā

Boost and a look back on C++

These days am a full time Java guy and the last time I coded in C++ was a little over an year ago. It was then I came across Boost library and I had heard that it packed a lot under the 5 letter library BOOST. Even though I haven’t much used Boost, since it is being made part of the C++ standard, I don’t want to be a person who knew legacy C++ and so was always keen to know about Boost. And thats when I came across this book on Boost. Its a cookbook style book which helps people who already know C++ and want to learn Boost. Here is my review on GoodReads :

Boost C++ Application Development CookbookBoost C++ Application Development Cookbook by Antony Polukhin

My rating: 5 of 5 stars

All those who want to use C++ in production will one day or other come across Boost Library. Being a coder who doesn’t use C++ as a primary language, but who wish to keep abreast of whats happening in the industry (and C++ is still not dead!), I always wanted to learn Boost. I had in fact downloaded boost about an year back, but haven’t used it much. A good tutorial was missing. And this cookbook definitely fills the void. It is not a beginners book who want to study C++. But its definitely an introduction to Boost. The author has made the cookbook way to give a very good introduction to Boost library.
What I liked: It is straight to the point. A no-nonsense book.
Boost is a large library and some of the it have been added in C++11. And some it is being said to be part of C++14. This itself tells that Boost is a library which every C++ programmer should be familiar of. And this cookbook is really a starting point to learning it. I should say that it is only the tip of the ice-berg, but it should make you capable of digging deep into the ice-berg

View all my reviews

Observer Pattern

Classification: Behavioral patterns
Description : Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically.

This pattern is sometimes referred to as Listeners in some frameworks.

Read about the pattern here.
The code sample can be found in my git repo.

In the example code I have done, there is a city, as with all cities many things can go wrong in a city. So city is the subject or the observable. To handle the emergency situations we have many emergency handlers. These handlers observe the city and take actions when needed. So handlers are Observers.
When something happens in the city, all observers will be notified. Some observers respond to the situation and some do not.