journal Life as a Web-Developer :: We’ve been here before
Over time your bound to repeat things you’ve already done before. Maybe not *exactly* the same – but simular enough to get inspired by your past self. Sounds familiar? I’m sure it will! Well this is a story about how things turn could evolve.
Haven’t we done this before?
As a good worker, you dutifully start your task by reading/asking what should you be doing first. A few lines in things are starting to sound kinda familiar – very familiar. Memories are starting to come back. And idd – you have done this before! It wasn’t completely identical – but close enough to give your a big boost. You dive in your archived projects and find the needed resources…
how things normally turn out
- Looking through the files you quickly find what you need
- copy it
- start changing
how things turn out .. when your a web-dev/developer
Looking through the files you quickly find what your after. It’s an older project though…made by several people…some who don’t work here anymore… ok no worries.. I don’t really need it running to grab what I need? (! 1) Ok lets see, we’ll need the table structures as well. **(! 2) **Oh this project uses migrations, forgot about that! nice! .. a lot of migrations.. Oh no.. **(! 3) **
**(!! 4) **We will need to have this project running (if possible) on a webserver and create the database before we can even consider to think copying things from it. Experience lets you see how things run without actually running the app – but cannot help with the database and migrations. You asses if it will be worth it. It will. How difficult can it be? Shouldn’t take lang, isn’t it? Here we go we:
- Create a new database – just on your localhost b/c setting up a new vagrant machine shouldn’t be needed right?
- Create a new user for said database
- Import the basic schema. (we would be done here if no migrations are used)
- You don’t trust the schema – since there so many migrations. You feel you have no choice then to run them.
- It’s a freshly checked out Laravel project -> need building of assets and downloading packages. You run composer update.
- Error #1 – seems like this project uses a not installed php extension.
- Look up package that uses it.
- Decide installing that extension on your local machine will be faster and useful in the future
- Error #2 – homebrew cannot find package
- Ok. we the package is renamed. Trying with new name.
- Error #3 -Error: Your Xcode (7.0) is too outdated. Please update to Xcode 8.2 (or delete it).
- #[email protected]! and let your hand forcefully land on your table. I ONLY WANT TO SEE THE TABLES!! ARGHHHHHH!!!
- Ok. Let’s disable that package.
- Why can’t I still comment out things in json?
- Lets download xcode in the main time as well.
- Open App Store
- Check Updates: nothing
- Oh wait it is still checking. Still checking. And checking. Screw this! Search “xcode”
- Looks like it was a new release. cool. downloading 4,53 GB.
- Store says it will probably take 15 minutes.
- Back to the app
- Error #4 – Silly human! you’r attempt to remember this package without my knowledge isn’t accepted!
- Google how to exclude a package from composer.json / add comments. I don’t want to delete it completely.
- Fuzzy feeling that your not alone with this problem: at least 4 different discussions about this thing are going on. But off course they all end with the same: you can’t. This is 2017 and we still have no real way to add comments to JSON. I know this is something that is very rarely needed but in the case of config files – like composer.json – it’s just a pain. Although it is also true that if I had this dependency already installed – or could install it with brew in seconds, this wouldn’t raise an issue .. now.
- Add workaround to comment problem: write a json property “comment” and remove all ” : ; from the copied package.
- Hope you’ll remember to add the package later (including the punctuation”.
- Remember you use Git – so this should even have been an issue in the first place..
- Hit composer update.
- Error #5 – The requested PHP extension is missing…. wait?! what? how?
- Decide it will probably be easier to try to install the extension. Check progress xcode instal = 4min.
- Silently praise yourself and be thankful for starting the install of the update when you did
- Cool! xcode is installed.
- Run composer update
- Ow…cancel that, we need that F# extension first
- Run brew
- Error #6: You have not agreed to the Xcode license. Please resolve this by running: sudo xcodebuild -license accept
- WTF. ok. at least there is a command for it.
- Run license accept comment
- Run brew
- Warning: something something about your home dir..
- Looks like brew is updating itself though.. fingers crossed.
- Error #7: Could not install b/c of conflict.
- Realise you’re trying to install the php55 version on a php56 machine. Doh!
- Change a 5 to a 6.
- Run brew
- Ok the extension is installed.
- Opening the php config file to add/enable it. Try to remember how. Take an educated guess.
- Restart servers.
- Try to find it in the php info log. feeling tired. so much text. screw this! Composer update will check for me!
- Composer update.
- Victory! Composer is installing :)) You’ve never felt this happy! Yeey!
- Realise it’s late and your really getting tired.
- Feeling dread seep in that you will not be building anything anymore.
- Feeling a sense of loss – you really had an idea to start creating and moving forward. Even though you only had a few hours left; it would have been enough to get things started.
- This project has a lot of packages. I hope no server/internet is going to fail me now.
- Relief – every package is downloaded. Things are looking up!
- Ignore deprecation warnings and recommendations.
- THE moment where all been waiting for! Yes yes! The migration! Exited you run the command to tell your Artisan butler to check the database files and update the schemas with all the migration files you saw! Yeesss this is happening.
- You hit < enter > a bit harder than should.
- Nothing to migrate.
- cry for lost time.
- silently realise that the datestamp in GIT of the sql file correspondents with the last changed stamp on the migration folder.
- feeling embarrassed
- feeling thankful for the lesson. This will not happen again.
- realise you learned a lot today.
- go to sleep
This is why:
- I don’t really like migrations. Sure there easy to build and make database changes trackable and version-able. But they add a level off complexity, especially in cases like this.
- You should always **always** add a timestamp to your SQL dumps and/or a version number.
- You should always **always** add that latest sql structure dump before closing the project.
- Avoid using packages that require specific, rare, special php extensions enabled.
- Avoid packages that hard check for 4. without a way to say “Yeah I know I will fix this later when I need it, just do the others at this time. ok?”
- Developing is an emotional rollercoaster and I’m sorry if I snapt at you – I didn’t mean it!
This is not fiction. This is reality.
No – it is not always like this. But somedays it is.
That’s part of the job.
Every webdevver has stories like these otherwise he/she isn’t really a webdevver.