Tag Archives: Software

Functcon

TL; DR

We believe that Functional Programming (FP) is going to be, and is currently, a disruptive force in mainstream programming. We want to help shape the community around that force to improve the larger software community. We will do this by building an open and safe community where newcomers and veterans can explore FP- their love of it, and how to use it to build awesome software. If you believe in this please sign up on the mailing list at www.functcon.com.

@Functcon is a #FunctionalProgramming #Conference built around a community of #safety. Click To Tweet

Our Value Statements

To promote a culture of success and safety to a growing community of functional programmers, we believe the following things:

  • Functional Programming is disruptive and will continue to be so.
  • Psychological safety is the most important thing to build a successful community.
  • Excellence in programming makes changing code safe.
  • Processes of continual improvement are necessary to achieve excellence.

Functional Disruption

Kate, my wife, and I believe very much that Functional Programming is a disruptive force in the programming industry. This old technology is seeing increasing attention as we are needing different approaches to solve today’s problems.

The simplest computers are gaining more cores and an application’s ability to use those cores determine its success. Not to mention the kinds of thoughts needed to solve the problem of analyzing the increasing mountains of data we are accumulating by the minute. These problems are a couple of examples of problems that have been difficult to solve using Object Oriented Programming (OOP) or Procedural Programming.

We see it as every mainstream OOP language starts to gain FP language constructs.  FP is appearing increasingly in podcasts. Functional Programming conferences are starting to appear and be successful with multiple hundreds of attendees.

We do not know if it will ever displace OOP, but we believe it will become as important. This means that to prepare for the future the industry will need people training in this skill set right now. The Dark Matter Developers are currently not learning this skill. You can see this by looking for accredited courses. Companies are not paying for accreditations in FP.

Dark Matter Developers are the strong majority of developers out there. That means there is currently a building skill deficit. As this skill becomes more in demand the culture surrounding that skill will become in demand. As a community, we can build a culture of success and safety.

Psychological Safety

Psychological Safety was defined by Amy Edmonson as the shared belief that a team is safe for interpersonal risk. She discovered teams that had this trait were the highest performing teams. Later Google found in their research that one of the most important traits to define a successful team was Psychological Safety.

For Functcon, we want to expand that definition from team to community. We believe by focusing first on Psychological Safety, we will build the most successful community.

Excellence in Programming

Excellence is not a word I like, as I state here. So, let me define what I mean by excellence. Excellence is the application of the most current knowledge about the best techniques and practices with understanding that the most valuable part of a project is its maintenance.

We believe by focusing on the very best of FP with this understanding of maintenance we can grow a valuable community.

Continual Improvement

It is virtually impossible to make something perfect, especially when you are dealing with a complex system. Everything you do is going to involve tradeoffs. Everything you do is going to be relevant to a given context which will move on and change under you.

So, we believe that Functcon needs to be about the continual improvement of the community, the code, functional programming, and itself. This will allow us to adapt and always remain at the top of the game.

Tying it together

If we manage to be the most successful community, with the most valuable practices, and we can adapt… Well nothing will be able to stop us. However, we don’t need to be the best to make an impact. If we even start to approach these things we will make for a better industry. Let’s do it together.

Call to Action

If you like what we are trying to do, please sign up for our mailing list. These names help us attract companies to help pay for the conference. Please tell your friends about us. Our page is www.functcon.com. And, of course, we won’t sell your information. Come hang out with us today!

I joined @Functcon mailing list. #Awesome #FunctionalProgramming #Conference https://functcon.com Click To Tweet

#NoEstimates Story Sizing

A way to determine if a story is small enough without estimating it.

TL; DR

“No Estimates” is a modern movement in software development that focuses on eliminating wasteful estimates. However how do you know if a story is small enough to be accomplished without estimating its size? There are a series of rules that when followed guarantees a bite size bit of work.

There are a series of rules that when followed guarantees a bite size bit of work. #NoEstimates Click To Tweet

Setup

“No Estimates” is built on continuous delivery of valuable product. That means that the business must be able to measure the output of a development team in near real time. If releases are regularly weeks or months away, then you leave the business with few tools to measure with. Faster the delivery the better they can measure. Stories need to be small enough to complete daily.

How do guarantee that the average story is small enough to be completed in a day without estimating?

The Rules

There are three rules that can be followed to ensure that a story is as small as possible. In all three rules, the word team means much more than the development team. It means the whole project team including the developers, the product owners, testers, management, executive management and anyone else who has a stakes in the product being delivered.

  1. Does everyone on the team have the same understanding of what the story delivers, and what need it addresses?
  2. Does everyone on the team have the same understanding of when the story is completed?
  3. Is the story free of any known preconditions?
Three simple rules for sizing stories in #NoEstimates Click To Tweet

Understanding

Gaining understanding about a story that crosses skill and role boundaries is difficult. To better communicate intention, we must be communicating simpler ideas. The first two rules do a lot to limit the size and scope of a story.

The first two rules also ensure that the right thing is done. A shared understanding means a shared vision and shared responsibility. If we understand what is to be done, and when it is done then we do not mistakenly build the wrong thing.

Preconditions

Once everyone understands what is to be done, and when it can be considered complete then we have a certain level of understanding about the story. If at that time anyone can think of a precondition that must be done before the story is complete, then the story is too big to be worked on. Maybe it is time to work on the precondition, or something else entirely.

The operative word in the last rule is “known”. We could spend an infinite amount of time looking for and understanding preconditions. It also goes without saying that we may find new preconditions as we start working. The important thing is that no preconditions are discovered in the process of gaining group understanding.

During the doing of the work, if we do discover a precondition we then need to decide if we continue or abandon the current story? Most often we can continue, especially if the precondition that was discovered meets the 3 rules, which means we must communicate our progress effectively.

Summary

In short, by following the three rules we can ensure work is taken in bite size chunks, even without estimating.

Let’s Encrypt AWS Lightsail with WordPress

SSL all things is a good thing, especially if you allow for user interaction. This includes clicking on links, writing comments or simply navigating your sight.

TL; DR

Let’s Encrypt is a free service that allows you to add Transport Layer Security (TLS) to any website for free. When you see the green padlock, this means that the sight is protecting its users from malicious scripts that inject them selves between the user and the sight. The documentation is well written but does not cover the what is needed to get it working on AWS Lightsail.

The Basics

I found this article that really describes the first half of the problem. It tells you how to enable TLS through the use of a Let’s Encrypt certificate: http://www.alondiamant.com/2016-12-20-using-lets-encrypt-certificates-with-wordpress-on-amazon-lightsail?utm_content=buffer27ff6&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer

What it doesn’t do is tell you how to ensure that only the encrypted version of your site is used.

Redirect

The rest of this article is assuming you are in an SSH shell.

To force redirection from http to https, there are some settings you need to change and delete.

First thing is to make a backup of your configuration. This way you can recover if you make a mistake.

sudo cp -I /opt/bitnami/apache2/conf/bitnami/bitnami.conf /opt/bitnami/apache2/conf/bitnami/bitnami.conf.bak

Then you are going to edit the config file. I will use ‘Nano’ to do this as it is a reasonably friendly editor for most people.

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami.conf

Once editing you will delete lines from the file. This can be done by using the arrow keys to move to the line and then pressing Ctrl+k.

You will want to delete everything between the <VirtualHost _default_:80> and the closing </VirtualHost> tags.

You will want to replace them such that the tag now looks like:

<VirtualHost _default_:80>
ServerName [your server name eg: www.mydomain.com]
ServerAlias *.[your root domain eg: mydomain.com]
Redirect / https://[your sever name]
</VirtualHost>

Then you will exit Nano by hitting Ctrl+x. You will be asked “Save modified buffer (ANSWERING “No” WILL DESTROY CHANGES) ?” Type a capital ‘Y’. Then when you are asked “Name of File:” just hit Enter.

Restarting Apache

Lastly you will need to restart Agache.

sudo /opt/bitnami/ctlscript.sh restart apache

Now to test your site.

Note

Your certificate is only valid for 3 months. So you will want to setup a Cron job to renew it.

About

R. Jason Kerney

Working For: Some Company, San Diego

Position: Agile Technical Coach

Experience: Around 21 years

Hobbies: Programming, Playing Board Games, Reading, Public Speaking, Spending time with my family

Note: Oh by the way, all opinions and ideas are my own and do not represent the place I work.

I am a developer who has benefited greatly from the programming communities of San Diego. Now I try to give some of that back. I have been a programmer for many years and have recently (3yrs) been focusing on the soft side of software; the people and the business.

Contact me, we are only a community if we communicate. I am most easily reached on twitter: @JasonKerney

Me

Twitter

https://speakerrate.com/speakers/177671-jason-kerney

https://www.linkedin.com/in/jasonkerney/

https://registry.jsonresume.org/JasonKerney

Current Talk

None at the moment

Git Hub

https://github.com/jason-kerney

Twitter

How to find me on the web

Publications:

Talks

2018

2017

2016

2015

2014

2010

2009

2008

Places I Have Contributed:

Programming Contributions:

Tutorials I Contributed to:

Contribution as a Conference Reviewer:

Meetup Session I Helped Run:

RPG to Learn Mob Programming

Tuesday, May 8, 2018, 5:30 PM

Hunter Industries
1890 Diamond Street San Marcos, CA

20 Members Went

Have you heard of the Mob Programming RPG? Learn the roles that best support the mob programming paradigm including Navigator, Driver, and even the Rear Admiral. For those who can make it early, the first 30 minutes (5:30 – 6:00) we’ll be networking. There will be light snacks. Since this meetup doesn’t have a sponsor yet, we’re depending on the ge…

Check out this Meetup →

People Who Took Interest:

Blogs about Me:

Interviews I Have Given:

Interviews I Have Given on Pod Casts:

Places Where I am mentioned:

Slides:

Greatness

I have been thinking about great teams and teamwork lately. Greatness is not something easily attained or held, but easily lost.

What does it take to be part of a great team? Click To Tweet

TL; DR

Greatness slips from our fingers at every moment, we must actively pursue it and not compromise for less. We must strive to ensure all voices are heard, that quality is maintained, and room to experiment is held. Anything less defeats greatness.

Acceptance

To ensure a great team, there must be an agreement of acceptance. All proposals must be met with a “yes and…” mentality. People’s views, emotions, concerns, and ideas need to be welcomed. Without this welcoming safety is destroyed.

Without that safety new ideas are killed before voiced. Trust degrades, and people fall into old habits. Greatness is lost, because innovation stagnates.

Acceptance can be achieved as long a few people are willing to champion it.

Uncomfortableness

The feeling of being uncomfortable signals the greatest chance for improvement. When the team “leans into” uncomfort and addresses the smallest things trust and acceptance grow. It is true that you need a seed of acceptance before this can happen; however, facing the feeling of being uncomfortable grows acceptance beyond its normal bounds.

Facing uncomfort, is very tenuous. Where acceptance can grow with a few champions, the ability to face things that make us uncomfortable can crumble with one criticism. This must be protected, and defended or the things that erode trust will remain hidden.

The most powerful and useful conversations happen when we solve real problems. If we cannot bring up those problems greatness dies.

Excellence

Once we have acceptance and the ability to face what makes us uncomfortable, then we need excellence. Excellence is the constant striving to do better than we are currently. This includes technical excellence, process excellence, teamwork excellence, and communication excellence; along with many other forms of excellence.

Excellence ensures quality of what we do, and constant improvement. It allows for us to make mistakes and learn. It allows us to revisit and revise old decisions. Excellence measures greatness, but by paradox excellence cannot be accomplished without the other things I mention here.

Experimentation

We don’t know how to improve, even if we do, the context will change. We cannot achieve excellence without the ability to experiment. The ability to make a judgement and be wrong.

Experimentation feels natural on the tongue, but we tend to subtly resist it. To be an experiment, four things must be true.

  1. There must be a possibility that the hypothesis is wrong.
  2. There must be a defined end for the experiment.
  3. Success and fail criteria must be known.
  4. The actions of the experiment must be defined.

In Short

Who does not want to be part of a great team? Greatness is simple to achieve but in no way easy. It requires acceptance of all ideas, the ability to face all uncomfortableness, a strive for excellence and continual improvement, and a willingness to experiment.

Greatness is simple to achieve but in no way easy. Click To Tweet

Without all these things, we cannot be great. With them we will always be traveling toward greatness.