When it comes to working as a business analyst, I’ve learned that there are just three things you need to keep in your mind when meeting with your customers (the project sponsor (gold owner) and domain experts (“goal donors”)) to gather requirements. These three thoughts will keep your meeting on track, lead you to the next question, and will help you know when your work is done.
This is a list of some of the applications I (Alvin Alexander) have written. I’ve included links to places where you can find more information about each app or application.
Just Be is a mindfulness reminder application for Android. Being an Android app, I wrote it in Java. You can learn more about it at JustBe.cc.
I’m reminded today that I wrote my Cato software way back in 2011. Cato, is a free CRUD generator for PHP, Java, and more. Never pay for a PHP/Java CRUD generator when you can get one for free — Cato is 100% free and open source!
Welcome to the main page for my Cato CRUD generator application. Getting right into it, here’s what the marketing department says about Cato:
“Cato is a free, open source, template-based, database-driven, GUI app that lets you generate text -- source code, configuration files, etc. -- for any programming language or tool, based on the tables in your database.”
If you know what the code generator does in Ruby on Rails, Cato works just like that, but it’s not specific to any programming language or framework.
“Do the most important thing until either it ships or it’s no longer the most important thing.”
~ Kent Beck
A SO page has a nice example of how to capitalize each word in a string in JavaScript:
As a quick example today, the following source code is for a Python feedparser script I wrote, based on the URL shown:
With the caveats that (a) I don’t know much about Python, (b) I don’t want to learn that much about it right now, and (c) I’m not concerned with performance at the moment, the following Python script does the following:
As I’ve gotten back into client-side web development -- specifically using Sencha Touch 2, a JavaScript framework -- I’ve quickly run into a problem in the Chrome JavaScript debug console. When I try to use console.debug() to debug an object, I get this non-useful output about the JavaScript object I’m printing:
[Object object]
There may be better ways to print the desired object, but I quickly discovered this trick to printing all of the properties of a JavaScript object:
Sometimes when I embark on little projects like my Scala file-find command, I think, “This is a waste of time, the existing tools are good enough.” But then, if I’m motivated enough — if I really want something — I think, “But I can use this better tool for the rest of my life...”
I just released the file-find command four days ago, and I use it almost every day while learning Flutter and Dart, so I think it’s going to be well worth it.
This “People don’t want to use your software” quote by @SHL seems pretty smart. And Gumroad does a pretty good job of keeping their software simple.
I was actually thinking a little bit of the opposite yesterday; I thought, “I could care less about Apple hardware, I just like MacOS, or at least I used to love what it used to be.” But in the end I don’t really love the software, I just like that it works how I think an OS should work, and it has a Unix terminal that I keep open all the time.
Using FPA, I quickly worked through several of our largest projects to determine our productivity rates, and also noted who worked on the projects, what technologies were used, along with a few other details. In short, in a few days I was able to create a database of our historical software development speed.
Just a quick note here today that if you need some example MySQL database tables, you can use these. I created them for some experiments I ran last night. They show the MySQL create table, primary key, and foreign key syntax:
“So much complexity in software comes from trying to make one thing do two things.”
~ a good quote from Ryan Singer (as seen on @CodeWisdom)
Paraphrasing someone tonight: “I worked on cool projects X, Y, Z with cool new technologies A, B, and C. They all failed. Nobody used them. The only app customers still use was written in lowly old PHP. And the customers love it.”
I took that as, if you build the wrong application, no cool new tech will save it.
I bought my first copy of Agile Software Development with Scrum, by Schwarber and Beedle back around 2002, I think. I was just thumbing through it last night when I saw that they use Function Points as a metric to demonstrate the velocity that agile software teams achieve, and more specifically use it to show that some teams develop software much faster using Scrum.
I didn’t know about Function Point Analysis back in 2002 — I didn’t become a Certified Function Point Specialist until about two years later — so I probably just skimmed over that line then, but when I saw it last night I thought it was cool that they used function points as a metric for software team development speed.
“Scope doesn’t creep; understanding grows.”
From Jeff Patton in User Story Mapping (something I tried to explain to people many years ago)
This image is from an article titled, Why don’t people use formal methods? I like the parts about writing “precise, unambiguous specifications,” and some other parts.
I like the “No New Rationale” rule, which I learned about in this blog post by Aaron Turon, who writes about the Rust RFC process:
“No New Rationale rule: decisions must be made only on the basis of rationale already debated in public (to a steady state).”
“At some point, a member of the subteam will propose a “motion for final comment period” (FCP), along with a disposition for the RFC (merge, close, or postpone). This step is taken when enough of the tradeoffs have been discussed that the subteam is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong consensus against that position outside of the subteam.”
“When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.
This seems to be the default plan in big companies. They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it’s hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design.
If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.
So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you ... The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That's where you can win big by taking the bold approach to design, and having the same people both design and implement the product. ”
~ I hope to write more about this at some point, but for now this is a long quote from a Paul Graham blog post titled, Hackers and Painters
