Monthly Archives: March 2014

PostgreSQL on Fedora

Posted on by

I bought (and started reading) the book Seven Databases in Seven Weeks in order to have better understanding of the different SQL / NoSQL paradigms. What are the pros and cons of each approach and play around with each type.

In this post I want to share the installation process I had with PostgreSQL on Fedora.
I will write a different post about the book itelf.

The Installation
I don’t know why, but installing PostgreSQL on the Fedora wasn’t as easy as expected.
It took me several tries to make it work.

I went over and over on the tutorials, read posts and questions with the same problems I had.
Eventually I made it work. I am not sure whether this is the correct way, but it’s good enough for me to work on it.

The Errors
During my attempts, I got some errors.

The most annoying one, was:

psql: could not connect to server: No such file or directory
 Is the server running locally and accepting
 connections on Unix domain socket "/var/lib/pgsql/.s.PGSQL.5432"?

I also got

FATAL:  could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied

Sometimes I got port 5432 already in use.

Took some time, but I managed to install it
I am not entirely sure how I made it work, but I’ll post here the actions I did.
(for my future self of-course).

Installation Instructions: http://www.postgresql.org/download/linux/redhat/

# install postgresql on the machine
sudo yum install postgresql-server

# fill the data directory (AKA init-db)
# REMEMBER - here it is: /var/lib/pgsql/data/
sudo postgresql-setup initdb

# Enable postgresql to be started on bootup:
# (I hope it works...)
sudo systemctl enable postgresql.service

The next steps were to run the service, login, create DB and start playing.
This was the part where I kept getting the errors describes above.

First step was to login as postgres user, which is created during installation.
You can’t start the server as sudo.
As I am (still) not a Linux expert, I had to figure out that w/o password for postgres, I’ll need to su from the root.

# Login
sudo -s
# password for root...

# switch to postgres
su - postgres

The next step was to start the service.
That was the painful issue. Although very satisfying after success.
After careful looking at the error message and some Googling, I decided to add the -D to the commands.
I didn’t try it before, as I thought it wasn’t necessary because I added PGDATA.
Eventually I am not using it.

So this is the command that worked for me:

pg_ctl start -D /var/lib/pgsql/data/

And now what…?

In my first attempts, whenever I tried to run a PG command (psql, createdb), I got the annoying error described above.
But now it worked !

As postgres user, I ran psql and I was logged in.
After that I could start working on the book.

Some Tips

  • Don’t forget to add semi-colon at the end of the commands 🙂
  • create extension tablefunc;
create extension dict_xsyn;
create extension fuzzystrmatch;
create extension pg_trgm;
create extension cube;
  • I didn’t have to modify any configuration file (I.e. pg_hba.conf).
  • README file /usr/share/doc/postgresql/README.rpm-dist

    • co

    Disclaimer
    This post was made out of notes that I wrote to myself during the hard installation.
    I am sure this is not the best (or maybe it is?)

    In the following posts I will share the reading progress of the book.

    I added a GitHub project with code I’m writing while reading the book.
    https://github.com/eyalgo/seven-dbs-in-seven-weeks

    (EDIT – I wrote this post at 2 AM, so I hoope there aren’t any major mistakes)

    Linkedin Twitter facebook github

    Advertisement

    The Node Beginner Book – Book Review

    Posted on by

    I have finished a few days ago a beginner’s book about Node.
    Name of the book: The Node Beginner Book , A comprehensive Node.js tutorial
    Author: Manuel Kiessling
    I liked it and the way it’s written so I would like to share it with you.

    I came across this book while looking for Node tutorials on the web.
    So first, here’s the site of the book: http://www.nodebeginner.org/
    It consists part of the first chapter of the book. As a tutorial and explanation.
    I started going over the tutorial and when I was done with this part I went on and bought the book.
    Another cool thing is that you can buy it from Leanpub as part of a bundle that has Hands-On Node.js as well. (I haven’t read this one yet).

    The book walks through a very basic Node server construction.
    Instead of just Hello World, we actually build a small server that can upload and show an image.

    It covers the basics, which I feel is enough to understand the concepts of Node and to give a really good kickoff for someone who is interested in Node.

    We start by installing Node and understand a little bit about JS.
    At the beginning there’s a clear explanation of the use case of what we’re going to develop.
    And, the importance of the architecture and how it should look like.

    Then, step by step, we build the server.js , the index.js, router.js and request handlers.
    I think that this is really important, as it emphasize a good approach of architecture design.
    The author emphasize how important is to separate concerns and create an organized code.

    Another really good aspect is the explanation of functional programming and how it helps in Node and HTTP server. Now, you’re not going to be a functional programmer after reading this book, but you will defiantly understand the concepts and get the idea.
    For me, it’s a really good thing. As a Java developer, I don’t use the functional paradigm, and it’s an important tool these days.
    (Yes, I know that there are many other functional languages. But that’s my point. By reading this book, I had a good opportunity to play with some functional paradigm.)

    The book gradually evolves the server creation.
    After we build the server.js, we start enhancing it.
    We build index.js file that holds mapping of routing.
    We build router.js that routes to the request handler.
    And requestHandlers.js to work with the different requests.

    Each part in the system evolves while reading the book.
    For example, at the beginning a function does not accept any parameter. Then it accepts some and later the parameters change.
    Every change is explained in the context and how it helps with aspects such as good architecture and design, asynchronous and other concepts.

    One of the examples, which I liked was why passing a callback function is important. The book shows nicely what happens if you run a slow operation (find in a file system), which is synchronous (not a callback function). Basically your whole server gets stuck.

    Towards the end, after we built simple yet flexible server, we learn some technical Node stuff. How to use external libraries with the package manager NPM.
    And by using it, we learn how to show an image, upload a file and rename it.

    At the end of the book we get a working Node server for upload and image and show it.
    It’s fun !

    I highly recommend it to anyone who wants to understand what Node is all about, but more than just the syntax.

    The author has another book, which I bought but haven’t read yet: The Node Craftsman Book.

    Happy Reading !

    Linkedin Twitter facebook github

    The Foreman Role in a Team

    Posted on by

    There is a lot of discussion about the need for a foreman role in a software team.
    Robert C. Martin wrote about it in Where is the Foreman?

    I recently read a post by David Tanzer who disagrees with Uncle Bob’s point: We don’t need a foreman

    The way I see it, a foreman role is important, but perhaps not as extreme as Uncle Bob describes.
    Let’s start by quoting the foreman’s role as Uncle Bob describes (in construction and in software):

    The foreman on a construction site is the guy who is responsible for making sure all the workers do things right. He’s the guy with the tape-measure that goes around making sure all the walls are placed properly. He’s the guy who examines all the struts, joists, and beams to make sure they are installed correctly, and don’t have any significant defects. He’s the guy who counts the screws in the flooring to make sure it won’t squeak when you walk on it. He’s the guy — the guy who takes responsibility — the guy who makes sure everything is done right.

    What would the foreman do on software project? He’d do the same thing he does on a construction project. He’d make sure everything was done, done right, and done on time. He’d be the only one with commit rights. Everybody else would send him pull requests. He’d review each request in turn and reject those that didn’t have sufficient test coverage, or that had dirty code, or bad variable names, or functions that were too long. He’d reject those that, in his opinion, did not meet the level of quality he demands for the project.

    I think that the commit rights is crucial point for many critics of this idea.

    I would like to suggest a middle way.
    A foreman role, but also team’s responsibility.

    In real life the team is diverse. Some are seniors, some juniors. Some are expert in a specific field, others in another field. Some are expert in TDD, some in design, some in DB and SQL etc.

    Here are the key points as I see it:
    A diverse team.
    A foreman who’s responsible for the quality and delivery.
    The foreman will sometimes make the final call. Even if there is still a disagreement.
    The foreman is also responsible that everyone works at the standards he introduced (with the help of the team).
    Everyone can commit. Not just the foreman.
    Everyone can suggest anything.

    Here are some reasons why it might work.

    1. Everyone can commit and everyone can see others’ commits. This means that there is trust between the team members. It also gives each member more responsibility. The foreman in this case will still look for all the things that Uncle Bob describes. But when he sees something wrong (missing test? A code that is not well designed?) then he will approach the person who committed the code and discuss what went wrong. The foreman will have an opportunity to mentor other team members and pass his knowledge.
    2. The foreman can be the peer, with more responsibilities. If Fred notices that people make mistakes, he will discuss it. The foreman has more responsibility. He needs to know to listen. He needs to explain and not blame.
    3. The foreman does not have to be the most experienced developer in everything. He can’t be. He may be most experienced in one or two or three fields. But not all. So if Alice is the most experienced DB developer, Fred the foreman should see that she helps other team members with SQL related stuff. He will still remind Alice about the procedures and code of the whole system.
    4. Sometimes the foreman will need to make decisions. Sometimes not everyone will agree. The foreman needs to know when to stop an argument and give the call.
    5. The foreman doesn’t need to have the sole responsibility for quality. But he’s the one that the management should approach. This is a tricky part. It’s hard to achieve. The team is responsible for the quality and delivery of the code. The foreman is responsible that the team achieve this. The foreman is responsible that everyone practices good coding (and everything that implies). The foreman is the one who needs to mentor team members who do not know how to bring quality code.
    6. The team is responsible for the architecture and design. As I mentioned before, the foreman will sometimes need to stop the discussion and make a decision. Each member of the team should have the opportunity to come forward with suggestions. Sometimes the foreman will bring the best ideas (after all, he’s supposed to be the most experienced), but more than once, other member will introduce the correct design. The foreman needs to listen.
    7. During the planning the team will estimate effort (E.g. will give points to user stories). Then, if the whole team is responsible for the design and architecture, the members will create the tasks with some time estimations. The foreman’s responsibility would be to see that everyone understands the priorities. He should be part of the team while designing and lead the design. If the team did not understand the priorities and didn’t bring quality code, it’s his responsibility. But also the team’s.
    8. The foreman should introduce new technologies to the team. The foreman should introduce the team coding practices. The foreman must pair with other members. Juniors and seniors. While pairing with juniors he actually mentors them. The foreman must see that the team does pair-programming with each other. The foreman is the one that establish code review habits in the team. As a foreman he can ask to review code even it was already done by another person. Sometimes it brings some antagonism, but as mentioned before, he has the responsibility and he’s the one that needs to answer the management.

    Uncle Bob suggested a rather extreme approach.
    Perhaps it suits in some extreme cases. He describes an open source project that actually work with several foremen: A Spectrum of Trust
    On the other side, David Tanzer shows correctly why this approach may deteriorate the team spirit and trust.

    I think that it’s possible to have a middle way.
    I think that a team can have a foreman, a person who’s in charge. But still let everyone be involved. Have trust, spirit and motivation.

    Linkedin Twitter facebook github