Functional Programming with Phunkie: Funky Parser Combinators

Phunkie is a library with functional structures for PHP. In this tutorial, Phunkie creator Marcello Duarte, head of training at Inviqa, explains how to create Parser combinators using the functional library. This post first appeared on the Inviqa blog, and was republished here with their permission.

Learning functional programming

Functional programming really matters. Pure functions (or functions with no side effect) are the perfect units of behaviour because we can rely on them to build larger and more complex systems. The greatness of functional programming relies on this power of composability.

That’s something I first came to believe back in the days of my licentiate degree on Computing for Management, during a semester in AI with Lisp. My course curriculum was mostly focused on C/C++, therefore I had to stay focused on where the skills demand was.

Thankfully, I’ve been able to reignite my love of studying functional programming here at Inviqa where we’re delivering more and more projects based on Scala, the general purpose programming language.

I’ve read "the red book" about three times (the Chiusano & Bjarnason one, not the Vaughn Vernon’s one). I took all the Martin Odersky’s Coursera courses, and I spent hours of my weekends watching videos and reading papers.

And I set myself a challenge: to do with functional programming what I did when I was learning TDD and created PHPSpec (a BDD testing and design tool for PHP developers) to help me learn; I decided to write my own functional programming dialect in PHP. And so Phunkie was born!

Now over to you. Learning functional programming means immersing yourself in a new paradigm, which can be challenging. It requires a totally different mindset for approaching problems.

So, by the time you can use functional programming to solve real-world problems, you’ll have spent hours grasping the new thinking or getting clued-up on the theory.

In this tutorial, my aim is to help fast-track your journey by going over my implementation of Hutton & Meijer’s Monadic Parser Combinators. Hopefully you will be able to see both the thinking and the usefulness of functional programming.

And, by using Phunkie, you can eliminate the need to learn Haskell to understand the topic. All you should need is some familiarity with PHP.

So let’s get started!

Continue reading %Functional Programming with Phunkie: Funky Parser Combinators%

by Marcello Duarte via SitePoint

6 Unexpected Mistakes That Keep Developers from Getting a Raise

Good performance is never enough.

Imagine working hard. You have an "above average" track record. You've never heard complaints — you even won the coveted "best employee" award last month.

So, your company decides to reward you by...

Demoting you.

Sounds bizarre and untrue, doesn't it? Who'd be thick enough to punish an employee for doing a great job?

Doing a Great Job Isn't Enough

AntarcticGorillas, a StackExchange user, shared the story above. He was genuinely frustrated because he did everything he was supposed to do, but ended up getting demoted instead.

Another StackExchange user dishes out some advice.

"Wow sounds like you failed to play the office politics game effectively. Good performance is never enough. You don't play the game and you lose, 100% of the time if you are in management."

He takes his bad advice even further.

"Ok now you have to salvage what is left. First, and I know you are going to hate this one, you have to make friends with your new boss. You have to get him to mentor you. You have to help him and not show your resentment. Yeah I know you resent him, you wouldn't be human if you didn't. But this is the time to take the high road. This guy clearly has the office politics down pat, you need to learn from him."

His advice is partially true. Good performance isn't enough. It's the baseline.

His advice to lie and manipulate? That stinks. But it isn't the worst part. It's the belief behind it.

I'm a _ Worker, I Deserve a Raise

As employees, we have the tendency to think we "deserve" it.

Developers do a great job. Most of us do everything we're supposed to do. Still, many are disappointed with the money they're making.

We know that many employers do their best to underpay. They walk a fine line, giving just enough to keep us on board, without affecting the profit margins they want.

It seems like your boss takes advantage of you.

You're working your hands to the bone. You're doing everything you're asked to do and more. When your company's in a bind, you deliver. Last minute updates? You get things done. Issues with scope creep? You handle it masterfully.

When you don't get the raise you deserve, it feels like an insult.

More often than not, the issue has less to do with your work performance and more to do with the intangible details. Behaviors and counterproductive decisions that alienate allies, partners and opportunities. These mistakes make it harder to get the raise we're hoping for.

Social conditioning leads many to ignore this stuff. "Ugh! Soft skills," you might say. But these unexpected, common mistakes impact raises every day.

Mistake #1: What I Deserve vs What I Want

There's a growing problem that's slowly eroding good will in the developer community.

Entitlement.

Open source entitlement is a great example. It goes like this:

1. Developer needs code to solve a problem
2. Developer finds open source code. It solves the problem
3. Code creates problems
4. Developer becomes angry, demands authors fix now. (For free!)

It's an oversimplification but it conveys the point. These open source authors aren't at our beck and call. It's a terrible idea to demand extensive tech support, then write angry letters when we don't get our way.

Mattias Petter Johansson over at FunFunFunction dives deeper into "developer entitlement."

When we feel entitled, we overestimate our abilities and our contributions. We swallow the lie our ego feeds us. "You deserve this. You're a senior developer after all." Developers with this mindset are bargaining on the wrong side of the tracks.

Here's how your boss thinks about raises.

"Holy crap, this is the guy that 10x'd our leads and sales in 18 months. The app he developed turned things around for us. We're going to need to spend more if we want to keep this guy."

See the difference?

They're not operating from an entitled mindset. They're approaching your raise from a transactional mindset, namely...

What am I getting for my money?

We're not entitled to a raise. We're not entitled to a promotion. Yet developers continue to approach salaries and promotions from an entitled mindset. I did a good job this year so, you "owe me."

They usually make their approach like this.

Which is the part where managers give their blunt and unsatisfying answer.

Nope.

Mistake #2: Being Right vs Being Respectful

Justin Keller, entrepreneur, developer and founder of San Francisco startup Commando.io wrote an open letter to the mayor. He was upset about the homeless in his community.

He didn't want to see them on his way to work.

"The wealthy working people have earned their right to live in the city. They went out, got an education, work hard, and earned it. I shouldn't have to worry about being accosted. I shouldn't have to see the pain, struggle, and despair of homeless people to and from my way to work every day. I want my parents when they visit to have a great experience, and enjoy this special place."

Maybe he didn't mean to convey feelings of contempt and condescension. But, his words were still hurtful and disrespectful.

He had a point.

No one wants to live in a neighborhood filled with homeless people. Homeless people don't want to live the way they do. We're human, it's normal to dislike these things.

Those who can avoid it, do so. Those who can't, endure it.

The general thrust of his argument is this: He doesn't want to deal with the problems that homeless people bring. Okay. But that's not really the problem here.

It's the othering of a group or type of people he views as beneath him.

That's the problem.

Developers struggle with the very same issue. As a developer, you're typically sure about your views. You're logical and precise. You're right and you know it, which is part of the problem.

You have a choice to make.

• Be right. You can show everyone that you are, in fact, correct. That your way is right. This comes at a steep price if it's handled poorly.
• Protect the relationship. You can treat others with respect, avoid humiliating them and allow them to save face when they're wrong.

Developers who focus on being "right" tend to be disrespectful. They burn allies and earn enemies.

Developers who focus on relationships first, discover their influence grows with those around them. They're viewed as trustworthy, and more people listen when they have something to say. Being right is easy when everyone values your feedback.

Getting that raise or promotion is tough if you're viewed as a snobby, know-it-all jerk.

Mistake #3: My Career vs My Loyalty

Google has been at the top of Fortune magazine's list of best companies to work for every year since 2007. The job perks are legendary. For many, a spot at Google is a dream come true.

So why is Google struggling to keep its employees?

A recent report by PayScale states the median employee tenure at Google is a little over one year. Its workforce has grown, but it's struggling to keep its people.

It's not because Googlers are unhappy.

84 percent of their 28,500 employees state they have a high level of job satisfaction which, as you'd expect, is one of the highest among the Fortune 500.

Other tech firms aren't having the same problem. The average tenure at Yahoo! and Microsoft is 2.4 and 4 years respectively.

Yikes.

The problem is loyalty. Loyalty is quickly becoming a thing of the past.

Employees are loyal to a fulfilling career, not a job — 78% would stay if they knew they had a career path. #HR #EmployeeEngagement https://t.co/TgHqkxS69Q

— Mercer (@mercer) December 9, 2016

It's not entirely our fault; We're given bad advice. The strategy is:"Don't ask for a raise, get a new job instead."

It's a destructive strategy that results in less trust. Employers limit the responsibility they give you because they believe you won't be here that long anyway...

Work has become this cutthroat environment where we all pretend to look out for the team, when in reality, we're looking out for ourselves.

If you're a sophisticated developer, you know.

At many companies, project managers and other developers are all too eager to throw each other under the bus for more money. When an opportunity comes along, these employees will eat each other for the chance to win.

Jumping from job to job only works for so long. Disloyalty catches up with you as your market value drops. There's no reason an employer should go out of their way to keep a disloyal developer.

Here's what loyalty looks like to them.

Continue reading %6 Unexpected Mistakes That Keep Developers from Getting a Raise%

by Andrew McDermott via SitePoint

6 Tools to Stop Your Devs and Designers Strangling Each Other

If you've been working in product development, web development, web design or most other areas where designers and developer work together, you've probably seen or heard at least one of the following (or something similar to it):

From the designers:

“We came up with a really beautiful design, but the developers really mucked things up. It's nowhere near what we designed.”

“How can we create a beautiful design if the developers will just screw it up?”

And from the developers:

“This design is impossible to replicate in HTML/CSS, this is as close as we can get.”

“Designing in Photoshop is easy, you don't have any limitations imposed by code. We can't fit this design into the development framework we are using”

Although you'll frequently hear comments such as the above, in my eyes, they're stemming from two main problems

1. A lack of good tools / communication frameworks in place leading to …
2. …a serious breakdown of communication between the designers and developers

In reality, designers and developers are very different from each other. Designers are right-brained, developers are left-brained. Those who think creatively need to establish a way to communicate correctly with those who think rationally / logically.

A way which works well for both.

The communication problem is made that much harder in today's environments, where remote working, different geographies, cultures, and languages, different timezones are all business-as-usual.

Having designers in one country and developers in another is the order of the day.

But designers and developers need each other. They need to communicate well if you want to create a good end product.

Start dating before living together

So, let's think of the developer-designer as a relationship.

Partners in a relationship need to understand what works (and what doesn't) for both of them before they can make more serious commitments.

The key to a good end-result: developers and designers need to start working together from the get-go.

Simply put, if a designer creates a design without the involvement of a developer, they're bound to have to go back to the drawing board often and get frustrated that their work as been ‘destroyed by the developer”.

If a developer is given a design which they had no involvement in, they're going to say that this design is impossible to implement and will have a hard time achieving the required end-result.

To create a design that works the developer should be present during the design brief to make sure that things are designed to an appropriate developer specification.

The following questions (and no doubt others) need to be figured out during the design brief and require input from both the developer and the designer.

1. What responsive framework (grid) system will be used to implement the design?
2. Are there any design elements which cannot be implemented using the selected framework?
3. Which elements can afford to be hidden at smaller screen sizes and what will that look like?
4. What text styles and fonts sizings are to be used?
5. Create actual videos or specifications of micro-animations to be used.
6. What imagery will be used and what kind of cropping will happen on smaller screens?

This is an exercise which needs to be done internally by your team. Figure out where you communication breakdowns are happening and then develop a set of questions which need to be fully specced (from the designer to the developer).

In essence, your designers and developer need to ‘date” such that they both understand each other, before actually committing to a design which needs to be developed.

As the design is being created, the developers should get involved frequently, such that potential development problems are identified early and resolved during the actual design.

Now that we've defined the theory, let's actually show you the tools we actually use to improve our communications between designers and developers.

How to get designers and developers to start working together

1. Use a constant communication process

Continuing with the need to have constant communication, you should implement SCRUM or another agile methodology.

Agile methodologies like Scrum emphasise the need for constant communication. All stakeholders agree on what is going to be built and they meet regularly to ensure everything is being developed to specifications.

We're not going to recommend or go deeply into the methodology to use, but, one thing is surely necessary.

Develop a process of constant communication.

For example, in Scrum, you have Daily Scrum 10 minute meetings which are meant to show the progress of the previous day and set a path for the current day. Any issues will be identified immediately and resolved separately from the daily meeting.

The Sprint Review – usually when a sprint is complete is a milestone – where both the developer and designer can actually see that progress on the design/development is according to the original vision.

By having both the designers and developers in constant communication, problems are identified and resolved quickly, before they get out of hand.

2. Use a good mockup tool

While PSDs are going to be necessary for the development, you won't be needing pixel-perfect designs for each and every screen in your project.

When the basic designs have been developed in Photoshop, you can then hurry things along with a good mockup tool.

Now, let's make one thing clear, mockup tools may be used by designers, but they're more likely to be used by your UX guys and developers. The favorite tool of choice for designers is an actual design tool, not a mockup tool.

Your mockup tool should be used as a bridge, between the people designing the requirements, the developers and the designers.

One thing to keep in mind - let everybody use their own favorite tool, don't force anything down anybody's throat.

Let the designers use their favorite design tool, Photoshop or whatever they prefer. Let the UX designers, the product managers, the business analysts use their favorite tool (typically a mockup tool). And then let the developers do their thing with whatever they want.

As long as there is a good line of communication, the tool they use is not very important.

Balsamiq

[caption id="attachment_153147" align="aligncenter" width="947"] Mockup of a one page application[/caption]

There are plenty of good tools out there, but the one we absolutely favor by far is Balsamiq.

Balsamiq has a full library of components and design elements which can be used to quickly create screens which need to be sent to the developers for implementation.

Balsamiq is available both as a desktop application for Mac or Windows and a cloud-based service.

UXPin

[caption id="attachment_153148" align="aligncenter" width="1200"] Mocking up a mobile design in UXPin[/caption]

If you're looking for a cloud-based service which is pretty much good for mocking up any design, UXPin has all of your bases covered.

Again, based on a comprehensive library of elements, you can web designs, Android or iOS apps, Bootstrap based screens, Material Designs, interactive UIs or micro-animations. It's as comprehensive a tool as it can get.

Moqups

[caption id="attachment_153145" align="aligncenter" width="1200"] Moqups used for developing mobile app mockups[/caption]

Whilst my preference is still with Balsamiq because, honestly, I like my mockups be just that - mockups, rather than near pixel-perfect designs, Moqups is another great wireframe tool.

With Moqups, you can create very high-fidelity mockups. Using the extensive libraries available within the tool, just like UXPin, you can go into quite a lot of detail into the design of your actual mockups.

3. Manage your project + tasks

Once your designers, developers and all the stakeholders have agreed on a way forward, it's time to actually start doing the work. When your start the actual job, job management software is great for quoting, time-tracking, billing and all the essentials of tracking your job.

Besides the actual job management (the easy part), you need to manage your project and the work which needs to be done.

It's during the actual project work where the problems often start to crop up, so there another few things which are critical to the success of a project.

First of all, each project must be broken into its parts and each step must be monitored for completion.

Secondly, your management tool of choice must be a single point of contact.

The biggest headache you can get is having ‘decisions” spread over multiple means of communication, email, Slack, your project management tool, face-to-face communication, phone calls. Always make sure that decisions taken anywhere all eventually end up in noted ‘in writing” on your project management tool.

Project Management Tools: Asana, Basecamp, and Trello

Ok, so rather than waste your time going through all of the most popular project management tools out there, I've bundled them all up into a single paragraph. Diving deeply into any of these specific tools has been done to death, so we'll leave this up to you to decide which tool is best for you.

All of the above tools have their strengths and drawbacks – it's a question of choice.

I've used all of them to varying degrees and all of them work well as long as you apply them well to the problem at hand.

Continue reading %6 Tools to Stop Your Devs and Designers Strangling Each Other%

by David Attard via SitePoint

8 Best WordPress Slider & Carousel Plugins of 2017

How to Create iMessage Stickers in Adobe Illustrator and Make Extra Cash!

How to Use Google Cloud Machine Learning Services for Android

How to Create a Social Media Marketing Content Plan in 7 Steps

Want to connect more with your target audience? Wondering how to deliver relevant social media content consistently? Planning your social media content delivery keeps your marketing on-message, making it more likely that you’ll reach your business goals. In this article, you’ll discover how to create a social media marketing content plan for your business. #1: [...]

This post How to Create a Social Media Marketing Content Plan in 7 Steps first appeared on .
- Your Guide to the Social Media Jungle

by Warren Knight via