Tag: methodology

PHP: What is the difference between .env files and .ini files?

That’s a good question. You might ask this when you are implementing a new project and trying to figure out where to store your secret configuration values.

Before getting into the difference, let’s state the similarities:

  1. Both allow storage of environment specific configuration values and secrets from outside of your codebase.
  2. Both allow retrieval of environment specific configuration values and secrets from outside your codebase.
  3. Both files use a key value pair type format.
  4. Both allow comments within the files.

So what about the differences?

  1. The names are different .ini vs .env
  2. The method of storing the data is different.
  3. The method of retrieving the data is different.
  4. The syntax is different.

That probably doesn’t answer your question though. You likely aren’t interested as much in what the differences are as you are in why you would use one over the other.

Why use .env instead of .ini or .ini instead of .env?

This is likely what you are wanting to know, why would you use one over the other. So let’s list some pro’s and cons of each format to help make the decision.

.env Pros

  • language-agnostic
  • allows referencing other .env values as variables
  • libraries like phpdotenv provide robust functionality

Let’s expand a little on the language-agnostic pro above.

First Scenario. You are coming to PHP from another environment, like Ruby, you are probably wondering where to put your secrets and configuration values for your code. A .env file just makes sense, these are supported in Ruby so there must be a way to add them in PHP. Voila! There is a package that supports .env files that you can easily include in your PHP code and you don’t have to think anymore about it. It probably doesn’t even occur to you to use the build in .ini support.

Second Scenario. You are using both server side JS, like Node, and PHP. You want to share configuration values between the two systems. Both support .env files allowing you to easily share your secrets between both languages.

.ini Pros

  • built-in PHP Support
  • allows grouping of values via sections
  • supports typed values via INI_SCANNER_TYPED
  • allows interpolating other config values and environment variables

.env Cons

  • requires third party library and composer to work
  • features provided change based on library used for loading
  • *some libraries load configuration secrets into globally accessible variables like $_SERVER or $_ENV which will could expose your secrets to code you don’t intend to

.ini Cons

  • requires familiarity with PHP

Which one should I use?

I’m going to give you the answer you don’t want to hear. That’s up to you. It really depends on the needs of your environment and your program.

As far as my personal preferences go. I don’t like including unnecessary dependencies in my codebase. Therefore, if I’m using PHP to develop my app, and I have no need to share my config secrets with other languages, then I would use an .ini file and the built in support for those that PHP provides.

A Few Ideas Regarding SCRUM Process

We’ve been using SCRUM at work. It’s certainly been a learning process. During that process I’ve learned that I’m not a very big fan of SCRUM. I’ll write more on that later. That said, I’ve come up with a few ideas which I hope will make my time, and my teams time, with SCRUM a bit better.

  1. Start measuring stories on complexity not time.
    It’s very easy for a story to be under-estimated. If a story is not estimated correctly, it will take longer and you will most likely miss your Sprint. Don’t think about time when estimating, we like to think we can get things faster than we actually can. Think, instead, about how complex something is. The more complex it is, the higher point it should get.
  2. Use a 10 point scale in your head when estimating.
    Depending on what you are using, the SCRUM point scale skips numbers. Our numbers are:

    0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, INFINITY

    When we see numbers like 13 we immediately think that they are “big” numbers. So when we estimate we tend to pick numbers under 13 even though the story being estimated might require a 13. So, I say pick a number between 1 and 10 in your head and then translate that to the SCRUM numbers.

    0.5 1
    1 2
    2 3
    3 4
    5 5
    8 6
    13 7
    20 8
    40 9
    100 10
  3. Take the larger of any numbers present.
    I’ve dubbed this Jeremy’s law. During the course of estimating you might find yourself wrestling between a 2 and a 3 in your head. Take the bigger number. If there is any doubt in your mind, you should just take the bigger number instead of committing to something that you are not sure of.
  4. Look back at similar stories points. Did we complete them or were they underestimated?
    Previous stories you have completed might be similar to the ones you now have to do. Or they might have a similar complexity. Rather than estimating a whole new estimate, use that information to your advantage. If, in the past a story like this took a long time, it will probably take a long time again.
  5. Forget about doing it right the first time.
    This will be the hardest for me. I like to do it right the first time. But when it comes to SCRUM the key is to get stuff done. Once you have something done you can then iterate on it. Now – I’m not saying that you shouldn’t program using SOLID principles. I am saying that it’s easy to spend a lot of time analyzing things. Just jump in there and start coding it up.Think of the story as not having to be totally complete. Think of it as a step towards being totally complete. Just get it done as fast as possible. Than pass to testing. Once it’s done we can reiterate on it to improve it. But the first goal should be to get something out the door.
  6. Do create follow up stories (discovery stories for what is wrong)
    During a SPRINT review a stakeholder might not approve the story to go live. We should create a discovery story then and there to figure out what further they need from the story. Create new stories based on the results of your discoveries.
  7. Once a story meets ac it is done
    As long as the original story meets the acceptance criteria we can consider it done. Anything that changes the AC should yield a new story with new AC. This will allow us to iterate on the first while keeping the first story in a “done” state.
  8. Be more pro active about sending too complex stories back to be broken up further.
    Big stories need to be broken up. It’s just how it is. Don’t feel bad about sending a story back to be broken up.
  9. Don’t take in a thirteen if possible.
    In our version of SCRUM, stories that are 13 points will take up the whole Sprint. And because we know that things usually take longer than we expect, a thirteen will definitely overflow the timebox. So, send it back to be broken up.
  10. Pull smaller bits more often into master.
    There are certain bits of code that we add during the course of a project that can be added to master. We split the stories up, but maybe we can also split the code up as well. Instead of pulling a huge change into master, let’s identify the things that can go to master as we go along.
  11. Push things out as frequently as possible.
    Avoid the big pushes and potential big breakages by pushing smaller bits of code out more often. We talk about this often and say it is a good idea, but we don’t do it. We don’t need to get stakeholder approval to fix a bug we find, so push the bug fix live. We don’t need stakeholder approval to fix performance issues – so push those live. We don’t need approval to repay technical debt – so push that live.I’d reccomend we push anything live that we can. The stakeholders like to bundle everything up into a gigantic push. We really need to let them know that a better way to do it is a little bit all of the time.
  12. Immediately create stories for what needs to be done as soon as it is known.
    I think we as developers should be more pro-active about creating stories. If we find something that needs to be done, create a story for it. It’s hard to prioritize these kinds of stories because they are not necessarily related to business initiatives. So, use your best judgment in when to pull it in. The key is, it’s not going to get done unless we remember to do it.
  13. Always be thinking of ways to improve the process.
    Don’t be afraid to get rid of waste. If we get rid of the “big” waste, it enables us to see the smaller waste. If something is wasteful, don’t be afraid to get rid of it or let someone know you think it is time for it to go.

I really hope these things help. Ideally I’d like to move away from SCRUM. However, if I’m going to have to use SCRUM then I might as well figure out how to make it better.

Do you have any ideas on how to improve the SCRUM process? What do you do? How did your teams make things better?