Here's what was popular in the PHP community one year ago today:
In this episode of "PHP Internals News" I chat with Gabriel Caruso (Twitter, GitHub, LinkedIn) about the "Ensure correct signatures of magic methods" RFC.
The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news
Hi, I'm Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 54. Today I'm talking with Gabriel Caruso about his ensure correct signatures of magic methods RFC. Hello Gabriel, would you please introduce yourself?
Hello Derick and hello to everyone as well. My name is Gabriel. I'm from Brazil, but I'm currently in the Netherlands. I'm working in a company called Usabila, which is basically a feedback company. Yeah, let's talk about this new RFC for PHP eight.
Yes, well, starting off at PHP eight. Somebody told me that you also have some other roles to play with PHP eight.
Yeah, I think last week I received the news that I'm going to be the new release manager together with Sara. We're going to basically take care of PHP eight, ensuring that we have new versions, every month that we have stable versions every month free of bugs, we know that it's not going to happen.
That's why there's a release cycle with alphas and betas.
Yeah.
I've been through this exactly a year early, of course, because I'm doing a seven four releases.
Oh, nice. Yeah. So I'm gonna ask a lot of questions for you.
Oh, that's, that's fine. It's also the role of the current latest release manager to actually kickstart the process of getting the PHP, in this case, PHP eight release managers elected. Previously, there were only very few people that wanted to do it. So in for the seven four releases it was Peter and me. But in your case, there were four people that wanted to do it, which meant that for the first time I can ever remember we actually had to hold some form of election process for it. That didn't go as planned because we ended up having a tie twice, which was interesting. So we had to run a run off election for the second person between you and Ben Ramsey, that's going to go continuing for you for the next three and a half years likely.
Yep.
So good luck with that.
Thank you. Thank you very much.
In any case, let's get back to the RFC that we actually wanted to talk about today, which is the ensure correct signatures of magic methods RFC. What are these magic methods?
So PHP, let's say out of the box, gives the user some magic methods that every single class have it. We can use that those methods for anything, but basically, what magic methods are are just methods that are called by PHP w
Truncated by Planet PHP, read more at the original (another 20573 bytes)
If you’ve ever attempted to read up on or start your own business, you’ll likely have come across this encouraging nugget of information – the one that says upwards of 90% of new businesses fail within the first five years.
That’s pretty alarming, but even more alarming is when you’re the designer chosen to create content for one of these entrepreneurial turkeys. It can be really tough when a client suddenly runs out of money and has to default on your payment for a project. Yes, you can sue them, but unless business suddenly picks up (or they have incredibly wealthy parents), you’d probably be wasting your time.
Knowing how to spot a business idea that is not going to work, or how to tell when a particular business relationship looks rickety and on the brink of collapse is an important skill for any designer to learn, particularly if you work with new startups.
There are a lot of upsides to working with new businesses – the energy and enthusiasm among the members of the team is contagious, and if you’re a designer getting in on the ground floor of a successful venture, you can find yourself in a very enviable position within the company in just a few years. However, if things go south, it can turn into a nightmare if you didn’t see it coming.
It’s helpful to know something about business yourself if you plan on working with startups. There are plenty of books to read, but in my opinion, the best way to learn about business is to start one yourself. Not only does it make sense financially for designers to have a side business, but the knowledge you gain from doing so will also be extremely valuable in your future dealings with entrepreneurial clients.
Technically, if you’re a freelancer, you’re already running your own small business, but even if you’re working in-house, it can be extremely valuable to learn the ins and outs of business. Even if you fail – especially if you fail – you’ll learn what works and what doesn’t, and why.
Be wary of business ideas that sound too strange or that don’t seem to make any sense. Does the idea sound just a bit too perfect, unique, and lucrative? Watch out. Anything that sounds too good to be true probably is.
Also to be avoided: businesses that don’t have any real competition or market equity. If the waters are too quiet, that’s a bad sign. It usually means that there’s no market for what the business is selling.
Perhaps counterintuitively, business ideas that seem to be unoriginal or that are jumping on a current trend actually have a better chance of doing well than unique businesses with little or no competition. Why? Because popular industries are more profitable, for obvious reasons. More people interested means there’s more money to be made.
This is why nobody is attempting to come up with a completely new, original alternative to the automobile – they work with what’s already popular and what already makes money. Reinventing the wheel is usually more trouble than it’s worth (except when it’s not, but chances are you won’t encounter anyone who manages to pull it off successfully).
Something every designer needs to know to avoid getting tangled up in business disasters is how to properly observe a potential client. It can be difficult to tell in the first meeting with a potential client whether their business will be a flop, particularly if you haven’t been freelancing for long.
But if you allow someone to do the majority of the talking for at least 5-10 minutes, you will learn more than perhaps you ever wanted to about that person’s behavior, management style, personality, and feelings about their mother-in-law.
People love to talk about themselves, and as a designer on the lookout for danger, this can be your best advantage. Listen far more than you talk – ask questions that encourage the client to reveal more information. Interview your potential client as much as they’re interviewing you.
Sometimes, a business seems perfect. The idea is solid, the market is strong, and competition is at a healthy level. These kinds of businesses can catch you off guard the most when they go south, because everything seemed okay on the surface.
But chances are, even these surprising failures have warning signs that show themselves well before you ever sign on to do any work. This is where it’s helpful to know the signs of detrimental management – why certain business owners and managers are successful and why others seem to cause chaos and turmoil wherever they go.
When meeting with a prospective entrepreneur client, take careful note of their demeanor and speaking style, specifically how they talk about their current or past employees or freelancers. If someone is trash-talking their people or uses too much personal praise (as opposed to team-oriented praise, which includes the entire group), that’s something to be wary of. It doesn’t always mean the company will go belly up, but it certainly won’t help matters.
Another type of red flag is clients who seem to have no regard for any type of budget. One of the top reasons many businesses fail is because of a lack of strict budgeting and an excess of profligate spending. If your small business client asks for work that you both know will cost an exorbitant amount of money, they’re probably not going to be a long-term client.
Moderation is what you want to look for when shopping for steady, repeat clients. You want someone who is financially responsible (but not cheap) and understands the budgeting required for a small business to be successful past the five-year mark.
Even if you don’t personally get caught up in the financial fallout of a bad business sinking to the bottom of the ocean, you want to avoid attaching your name as a designer to too many failed commercial ventures. It doesn’t look good on your resume, and once you encounter a genuinely successful startup, they will take one look at your track record and immediately draw conclusions about your involvement in each fiasco.
You may have had nothing to do with the company taking a nosedive, but your name was thrown into the mix, and that makes you a suspect. They may even see you as a “bad luck charm” – people are more superstitious than you would believe.
Successful businesses don’t want to invite freelancers or employees who may bring about failure. So it’s important to cultivate your intuition when it comes to bad businesses.
Learn how to spot bad ideas when you see them and avoid becoming the opposite of a designer rabbit’s foot!
The post Dealing with Terrible Business Ideas from Your Clients appeared first on Speckyboy Design Magazine.
Calling all PHP developers! Want to wrap your brain around functional programming? Are you sick of reading tutorials about this magic "monad" thing but having no idea how to read Haskell? Then this book is for you.
Announcing Thinking Functionally in PHP, by yours truly, available now on LeanPub.
Continue reading this post on PeakD
Editor’s Note: This is the second in a five-part series on refactoring and modernizing PHP applications. If you were to identify the most expensive part of any development project, what would that part be? The planning phase? Acquiring copyright or intellectual property? Marketing and advertising? All of these would be wrong. The most expensive part […]
The post Part 2: Code Is The Most Expensive Solution appeared first on BrandonSavage.net.
Latest PECL Releases:
Volt::convertEncoding to no longer using iconv for a fallback since it causes issues with macOS #14912
PhalconDbDialectMysql - unquote numerical defaults #14888, #14974
FALSE to Enum::DENY #14974
PhalconHttpResponse::__construct checks content data type. Now a TypeError will be thrown if incompatible data type was passed #14983
PhalconFlashFlashInterface's methods: error, message, notice, success and warning #14994
PhalconMvcModelInterface::sum #15000
PhalconMvcModelCriteria::getLimit so that integer, NULL or array will be returned #15004
PhalconMvcModelManager::getCustomEventsManager to return NULL instead of boolean FALSE if there is no special events manager #15008
PhalconMvcModelMetaData::getDI so that now it will throw a PhalconMvcModelException if there is no DiInterface instance #15011
PhalconHttpRequest::getJsonRawBody to use json_decode instead of PhalconJson::decode #14936
PhalconFactoryAbstractFactory to expose getService which will throw an exception if it does not exist. Removed checkService and adjusted all references in newInstance() calls. #15038
PhalconHttpMessageResponse, PhalconHttpMessageServerRequest and PhalconHttpMessageUri to work with clone. #15040
PhalconMvcModelQueryBuilder::getPhql to add single quote between string value on a simple condition #14874
{{ ... }}) #14476
Tag::friendlyTitle to correctly convert titles under MacOS and Windows #14866
cache fragments and thus searching for the viewCache service (deprecated for v4) #14907
IN operator precedence in Volt #14816
PhalconAclAbstractAdapter's methods: getActiveAccess, getActiveRole and getActiveComponent #14974
PhalconAnnotationsAnnotation's properties: $arguments and $exprArguments #14977
PhalconAnnotationsAnnotation's methods: getArgument, getName and getNamedArgument #14977
PhalconHttpResponseCookies::setSignKey #14982
PhalconConfigConfigFactory::load and PhalconConfigConfigFactory::newInstance to explicitly indicate the return type as PhalconConfig instance #14978
PhalconDispatcherAbstractDispatcher::dispatch
PhalconDispatcherDispatcherInterface::dispatch
PhalconFilter::get
PhalconHttpMessageAbstractCommon::cloneInstance
PhalconHttpMessageAbstractCommon::processWith
PhalconHttpMessageAbstractMessage::withAddedHeader
PhalconHttpMessageAbstractMessage::withBody
PhalconHttpMessageAbstractMessage::withHeader
PhalconHttpMessageAbstractMessage::withProtocolVersion
PhalconHttpMessageAbstractMessage::withoutHeader
PhalconHttpMessageAbstractRequest::withMethod
PhalconHttpMessageAbstractRequest::withRequestTarget
PhalconHttpMessageAbstractRequest::withUri
PhalconMvcModelBinder::findBoundModel
PhalconValidation::getEntity
PhalconValidationValidationInterface::getEntity
PhalconCrypt::$key to satisfy the interface #14989
PhalconDi::getInternalEventsManager #14992
PhalconFlashAbstractFlash's methods: error, notice, success and warning #14994
PhalconTranslateInterpolatorFactory::newInstance #14996
PhalconMvcModel::sum #15000
PhalconMvcModelCriteriaInterface::getLimit and PhalconMvcModelCriteria::getLimit to follow documentation and original purpose #15004
PhalconMvcModel::count and PhalconMvcModelInterface::count to reflect original behavior #15006
PhalconMvcModel::getEventsManager to reflect original behavior #15008
PhalconMvcModel::average and PhalconMvcModelInterface::average to reflect original behavior #15013
PhalconMvcModelMetaData::getColumnMap and PhalconMvcModelMetaData::getReverseColumnMap to reflect original behavior #15015
PhalconMvcModelMetaDataInterface::getColumnMap and PhalconMvcModelMetaDataInterface::getReverseColumnMap to reflect original behavior #15015
PhalconMvcModelCriteriaInterface::getColumns and PhalconMvcModelCriteria::getColumns to reflect original behavior #15017
PhalconDbColumn::getSize and PhalconDbColumnInterface::getSize to reflect original behavior #15019
PhalconDbColumn::getAfterPosition and PhalconDbColumnInterface::getAfterPosition to reflect original behavior #15021
PhalconMvcModelManager::executeQuery and PhalconMvcModelManager::ManagerInterface to reflect original behavior #15024
PhalconMvcModelResultset::getFirst and PhalconMvcModelResultsetInterface::getFirst to reflect original behavior #15027
PhalconMvcModelQuery::_prepareSelect to properly prepare a SQL SELECT statement from a PHQL one #14657
SerializerInterface usage for PhalconMvcModelResultsetComplex::unserialize as well as PhalconMvcModelResultsetComplex::unserialize #14942
PhalconTranslateInterpolatorFactory::$mapper as well as PhalconTranslateInterpolatorFactory::$services in favor of PhalconFactoryAbstractFactory ones #15036