I’ll be out of communication starting Friday till about the 5th of July. Taking a much needed vacation. Might be able to put in some time on a library or two while flying; but for the most part. I’ll be
See you happy people when I get back!
(Preface: I am a full supporter of CLI tools, UI tools are nice but should not be depended on for day-to-day workflow).
Came across this interesting UI tool from NomadPHP‘s weekly mailer. ComposerCat. It visually displays the contents of Composers composer.json and installed packaged. It’s in beta but looks to do everything it says on the tin. Check it out.
Anyone who has sat through the process managing a project know, whole heartedly as a fact, no matter how much something is planned and scheduled something else will always go wrong. Believing this as fact one should never, ever, plan a time line or effort estimation based around
everything working as planned.
working are so far removed from each other the relationship is vague at best. No matter how many times we build the same CRUD application or data pipeline, or CI/CD process; always leave yourself some buffer time to correct unforeseen issues.
As a general guideline the less I know about a requested change the higher my effort estimation; almost geometrically. As an example:
- 80 hours to write a single data object CRUD UI
- 40 hours to write a single data object CRUD UI with defined fields & validation
- 20 hours to write a single data object CRUD UI with defined fields, validation, and user story documentation
- 8 hours to write a single data object CRUD UI with defined fields, validation, user story documentation, and visual mock ups of the expected UX
Now at some point I hit a floor where effectiveness just simply keep up with the continued reduction in effort. But at that low of an effort estimate we are basically wizards doing magic as far as non code people are concerned.
Some people will responded with ‘but estimates that high scare away clients’; This is very true and factual. However, my response is this: do you really want to work with a client who has not clear answer or concepts of what the results of the effort should be? Think `moving goal posts` but not having a goal post to begin with.
TL;DR: Always buffer your estimates, even if you know everything that needs to be done.
Every year my employer has a holiday party. This past year I rendered out all the projects we had worked on and put them in a loop on the big screen. The video renderer we used is called gource. Here is the
gourcing of the current project.
Edit: So youtube is being…well Youtube and keeps deleting the video. Guess I’ll try again later :S. Still have it here so maybe twitch or something else.
#1 Stop blaming companies for bad code you wrote. Yes there are influences, but it was YOU who created it, not them.
#2 Stop blaming company for not training you, if you didn’t negotiate it upon hire. It is up to you, not them, unless stipulated.
#3 Testing is part of development, not an add on. Do it.
#4 Be professional, it is what you were hired to be. Sometimes it requires you to say no. It is your job.
#5 If you feel “iffy” about a company during interviews, get out before you’re hired. It will not get better.
#6 Nobody writes perfect code. Refactor often. Don’t expect a company to allot time, you allot it. Leave it cleaner than you found it.
#7 Use source control ALWAYS. There’s no excuse for not using it. It saves time rather than adding it.
#8 Stop using FTP in production!!! PERIOD! No human should be uploading ANY code to production.
#9 Use a proper editor that saves YOU time. This is different for everyone, but find one and learn it inside and out.
#10 Be good to yourself, and others. Nobody else will.
Source and all credit to Adam Culp.
…came across this conversation this evening. Interesting topic abut where tests logic should live. https://dev.to/rtfeldman/where-should-tests-live
So funny thing. As a general rule of thumb each environment is suppose to reflect production as much as possible. At work we use Codeception to run acceptance, function and unit based test. In said Codeception we have the BuiltInServer that will serve up the response to the testing request (say fro functional testing). Well `php -S` and nginx return very different things when the post body is over the set limit…
…guess who spent way to long trying to figure out why actual requests where responding correctly but the functional tests where failing :S.