LaSalle Software News #12: New Software Site, New Software Version

Tuesday November 1st, 2016

Episode Summary

Welcome to my twelfth LaSalle Software News podcast.

This is Bob Bloom, from Toronto Canada. 

Today is Tuesday, November 01st, 2016. 

I publish LaSalle Software News monthly, at the top of the month except for September, to update you on my LaSalle Software. 


LaSalle Software is my free open source Software, built on the Laravel Framework, making custom web application development affordable for my clients.

LaSalle Software includes a content system, user and login management, a normalized customer database, an administration back-end, customized admin form automation, and more.

LaSalle Software is my way of getting wonderful owner managers with underperforming WordPress sites into modern custom web application development. Unlock your RoI!



Lots of good things to convey...

Reading the SoundCloud docs, the move may be more work than I thought. Moving this podcast to SoundCloud is a go, but not to be in the middle of everything and completing nothing, I will finish the other stuff first.



My New LaSalleSoftware dot ca site is now live. It's not quite what I originally envisioned. It's text heavy, resembling a blog more than a marketing site. On the one hand, I berate myself for not sticking to a traditional software marketing site. On the other hand, my goal is not to promote downloads, nor am I selling software. My goal is for qualified clients to reach out to me.

A software site that is not selling software, nor signing up people for licence and support subscriptions. That's my new site.

Worse, a normal site tries to convert the highest percentage of visitors as possible. Not me, I want people to self-qualify. I set up the site so people click page to page. I want people to understand that doing web apps is a different concept than doing websites. I want people to know my take on what this concept is. 

People expect traffic from search engine results and from links from other sites. Naturally, not me. Well, not entirely. I expect people to visit my site because I talkeAfter a month of mulling it over, I am pretty sure I need to do version 2.0.d to them. Or, they read an article on my blog. I have a blog site, this podcasting site, repositories, and I'm Twitter. 

My mindset is that someone who is seriously considering contacting me will look at most of these things first. is part of this wider context. Or so I tell myself. 

I know that having conflicting messages, even conveyed subconsciously, destorys conversion. So there's a very good probability that people who should be contacting me will not contact me. At this stage, I'll just have to see. Naturally, I'll want the web apps I do for clients to be aligned: the domain name, the value proposition, the affirmative steps to the call-to-action, the call-to-action, the conversion action, the follow-up. 

One of the hardest things was defining my unique sales proposition. Or, in my case, simply expressing precisely what it is that I am doing. At least I've been consistent all the way through: to make web app development accessible for my clients. I am putting this line everywhere: "LaSalle Software is my free open source software, built on the Laravel Framework, making custom web application development affordable for my clients". 

I need to memorize that line -- wait a second, I just wrote it on an index card. How many times have I fumbled for a quick elevator-pitch style shpiel when talking to people who are genuinely interested in hearing about my software? Well, now I have that elevator pitch. Naturally, I don't like it, it leaves way too much implied. But that it really the point, isn't it, to convey the "gestalt", then pause and wait for a question. The last thing you hear is the first thing you remember, right, so "affordable for my clients" is supposed to be the the thing people first ask about. Which means that we talk about the benefits, not the technology. This is the theory in action, right? This is what is supposed to happen, right? I conjured this up all by myself, without focus groups, without role-playing, without rehearsing. All I have is a litany of failed conversations and bad memories. A healthy basis for solid marketing. 

A standout experience in my Joomla days was at a Toronto Joomla meet-up. I could not explain my LaSalleMart component in an elevator-pitch manner, instead being tongue tied after being asked enthusiastically about it. Everyone in the room was listening, and when I fumbled the answer, someone said that that was so typical of developers who could code but can't market their stuff. I tried to be a Good Sport, but I was seething, because I was fumbling the translation from technical Bob speak to regular speak, and that processing was very slow. 

Another standout experience was at last year's True North PHP Conference. People genuinely asked me about my software, and I fumbled, bumbled, and stumbled the explanation. A few people chastised me for not having an elevator-pitch style answer, in the most friendly way. I will say that I released version 1.0 a year ago, and was not confident about my software like I am now. On the other hand, so what? 

Today, I am confident about my software. I am ready to onboard wonderful long-term clients. I have my marketing stuff done -- new site, new business cards, updated profiles, networking. And, an elevator pitch!



I am the organizer of the York Region PHP Group. Although PHP groups are officially called "user groups", I have already taken out the word "user". Although PHP users are developers, placing the word "user" in the name attracts non-developers who mis-understand the technical nature of the Group. 

Well, again, I have a standout Bad Experience with this "user vs programmer" thing. This was an ongoing issue back in my Joomla Toronto Group. There was a developer side to the group, and a user side to the group. The bias was to be more a user group. Which made total sense. And, which caused me to irritate people. 

My personal opinion is that open source software is technical manna from heaven. Joomla is free open source software. Just like WordPress. Just like LaSalle Software. The PHP programming language, the Laravel Framework, are FOSS. Available for free. You can basically do what you want with the software for your own use -- the idea with open source is that the changes you make for your own use, you upload what you've done -- to the extent that you are not revealing proprietary info, I assume -- to "give back", so others can benefit. Anyways, the software is absolutely free. And not only is it free, but you can read the code itself. Millions upon millions of dollars of development time went into the software, and you can just download it for free and look at the code directly. Is that amazing or what?!

When I pointed this out, my enthusiasm was not universally shared. The software was, how shall I put this, somewhat idiosyncratic. It did things because that's what was coded. Sometimes the best answer was a source code dive. I'm all for projecting the source code onto the screen and doing a walk through. Ah, well, no way most "users" want to see source code. We can talk about the code, we can talk about our interpretations about what we think the code is doing, but doing a walk through of the source code that is freely available for download -- we don't do that. Because we are users. 

Well, that does not sit well with me. You know why? Because the money is in the technical stuff. 

How many times have I heard that "I am just a user, that technical stuff makes my eyes glaze over"? Countless! Can I tell you a secret? I could care less that your eyes are glazing over. The money is in the technicals.

Remember the line, "The Medium Is The Message"? Well, I believe that "The Technology Is The Business".  Oh boy, I can't say that, that's just narcissistic hogwash from a self-centered developer. Well, for those people with underperforming WordPress sites, who are tired of hearing how magical SEO and social media are but don't see the results, maybe a light bulb will go off. A web app is not a website -- these are different concepts. No matter what business you are in, you can make more money with technology. There is no cookie-cutter answer to how.  

The idea right now is to do your own API's. So that your data is available to third-party software. Or, just to make your data available to your growing customer-facing technologies. Offer a superior customer experience via technology, and your sales will go up. 

Who is creating value? The user? Or the programmer? I hate to be the one to break it to you, but the programmer is creating the supra-RoI. This is what I believe. One of the greatest software value-added creations was created by extremely technical software engineers, originally for other software engineers, and was released as FOSS so other software engineers could use it. This was the Jenkins continous development server, and any intrepid user could snag this incredible server for free. Not easy to use, not easy to learn, not easy on the ol' eye glaze thing. But a massive game changer. Struggling with continuous development early on yield supra-profits. Not without pain. But the possibility of making way more money from custom software development than your competitors was real. That above normal rate of return is diving now, because the CI technology is more and more accessible. It's becoming a standard thing, so not using CI costs you profit opportunities, but using it does not not necessarily makes you more money than your competitors. Although I don't think we are quite there yet. 

Front-end technologies. Who is creating that? Users? Did a user create VueJS? Did a user create the new Yarn? Did a user create the Laravel Blade templating system? I think not! A user would be wise to be up on these tech trends so that they understand where to focus their investible dollars for the best return. 

Yeah, I took the word "user" out of the York Region PHP Group's name. I don't want people complaining that the meet-ups are too technical. A PHP "user" are programmers, so the more technical the better. And the business value of technology is created by techies, not non-techies. 

I know that my clients are not technologists. I don't want my clients to be technologists, I want my clients to be very good at their business. I want my clients to have a visceral type of understanding that custom software development is itself a profit center and is worthy of effort, focus, and investment. That's a rare client! 

Boy, did I veer off topic, onto something else that is on my mind!



After the True North Conference, I am starting on LaSalle Software version 2.0.

For the first time, so it feels, I am not starting a whole new version because something external made the software out of date.

The underlying framework did not undergo a sudden overhaul; nor have the developers stopped working on it; nor have they silently decided to make key promised features private but outwardly keepi up the pretense of future releases; nor have the developers taken forever to release the production version; nor have there been any internecine political intrigue resulting in questionable code. 

It is downright refreshing to be able to tell you that I will be working on a fresh version by choice. 

It is refreshing to tell you that I'll be using LaSalle Softweare version 1.2 until version 2.0 is out. There is no reason to stop using v1.2. 

I do not feel the pressure to produce v2 like I did with v1. That in itself is about the most refreshing thing about it. 

The crux of it is: LaSalle Software needs a real API. That is the bottom line. 

"API" stands for Application Programming Interface. The full name is so sleep inducing that we might as well pretend that API is an actual word.

API means no screens. No forms. All those things that you are used to seeing on a website. Well, there is literally nothing to see here folks!

An API is a separate thing. Separate from an administrative area. Separate from the front-end. Separate from you smartphone and tablet app. It's a whole separate thing. 

API is data. You want data, you fetch it from the API. You want to add data? You give the data you want to add to the API. 

Those of you waving your arms up and down at me that an API is more than just data, I know. But let's just leave it at that for now. 

LaSalle Software needs an API, and I need to learn how to do API's. So there's the impetus. 

Starting a-fresh, I can do software testing from fresh. I can set up continuous integration from fresh. 

The API, the software testing, the continuous integration -- I will finally do these things. The only way to learn is to do it, so that's what I'll be doing. Full cycle software development -- it's exciting!

The new Laravel version 5.3 is not a breaking change. I feel emphatic that I must stress this fact. Laravel 5.3 is a very good version, and I want my LaSalle Software to use it. I started upgrading my packages, which are based on Laravel 5.1 LTS, but decided to stop because the better thing to do is to do a re-write. 

I want to interject here that I am not interested in this taking another two years. If there's one thing I've been thinking about late at night, it's that I need this version to come to fruition fast. I've come up with a few answers.

Most importantly, I already have version 1.2. As I mentioned, this code is not obsolete. I'm starting fresh, but not at zero. This time, and how sweet it is, I do not have to throw out my existing code.

LaSalle Software v1 is organized into installable packages. These packages mimick an API set-up. There are packages called "API", which are not true API's but were meant to house the data intensive code. These packages do not have any screens, just like an API. These packages receive internally generated "requests", and the return "responses" back to the other packages. I've taken great pains to standardize these internal "requests" and "responses", so there's opportunity to use the code. If not use 'em, then at least to extract the best things. Because, of course, I'll be refactoring. Purely from my existing software organization. 

Another reason why development will not take two years is because I am convinced I will need less code. I am pretty sure that things will not get more complicated, but they will get more simple. How? Refactoring existing code will be a big help. Laravel 5.3 will be a big help. Between you and me, I purchased Laravel Spark and will continue to study its codebase, which Taylor -- Laravel's author -- created -- this will help. 

I will also need less code because the command bus design pattern that I used -- well, that's going buh-bye. In v1, you submit a form in the admin, that data is put into a command bus via a data object, and that object is then "thrown" to the API package. Ooooh, this is not how it's going to work in v2, because that's not how it works with API's. I can dispense with the entire notion of a command bus and instead use one line of code to get the data to the API. 

I guess you could say that the LaSalle codebase will undergo a cleansing. 

Another thing I did was use a custom type of "response" in order to get the data from the API packages back to the admin packages. Well, in v2, I'll just use genuine request and response objects, and completely forget about using anything custom. So that's a bunch of code I won't need. 

I haven't told anyone, but I'm going to do something else. I'm going to reach out and ask people for opinions and help. It kind of dawned on me that I am doing an open source project, and that project includes ecommerce, and maybe it would be nice to get a few tips. I have no ambitions about LaSalle Software growing in popularity, so I'm not trying to pre-engineer a growth curve. I wouldn't mind getting some advice here and there, and being a Laravel based FOSS project, I'm sure some people wouldn't mind purveying some advice. 

One area of advice is with the API schema language called Swagger. Ok, it is now known by a different name. Specifiying the API's in Swagger, and then testing the endpoints. There is a new Laravel package that generates boilerplate Lumen from Swagger files, including boilerplate tests. That is interesting. 

Another way to speed up v2 development is to not do ancillary packages. The mail packages, the project and to-do packages. Honestly, these can wait. The customer database -- no, gonna build these into v2.

I am excited that I'll have an opportunity to refresh the admin with VueJS. VueJS is a javascript framework that is very popular in the Laravel world. The existing display I am using in the admin is a bit frustrating. 

I think once I know how I'm going to do the API's, because doing API's is a whole new thing for me, things will settle down. 

Version 1 represented a monumental need to learn. It was not just Laravel that I needed to learn, but all that was involved with web applications. My coding skills took a turn for the better. 

Version 2 represents another monumental amount of learning. API's, Laravel's Lumen framework, Swagger, testing, continuous integration, Laravel 5.3. 

Looking forward to it!




Enjoy a profitable month!


You have been listening to a production. Opinions expressed are not necessarily those of SouthLaSalleMEDIA dot com, nor of the organizations represented. Links and materials discussed on air are available in the Show Notes for this show. Information contained herein have been obtained from sources believed to be reliable, but are not guaranteed. Podcasts are released under a creative commons licence. Some rights are reserved. Email correspondence to the attention of Bob Bloom at info at SouthLaSalleMedia dot com.


Monthly report on the good, the bad, and the ugly of my ongoing LaSalle Software development. Produced by Bob Bloom, founder and developer of LaSalle Software.

      All Episodes