Yesterday was the first day in several I could commit to real time towards D* again. After getting back up to speed and making the status post I went on into the API development again. I was able to make some good progress on some brand new endpoints. The first one I worked, which is the first that needed from scratch coding of the main code, was the Tag Followings controller. The day before I had struggled getting Rails to make the POST for creating tags work against the spec. However after talking it over and thinking about it it was the spec that needed changing. In another software framework I could just make it work but relying on the auto-wiring in Rails brought the design flaw nature to light. With a simple change starting yesterday real development of the Tag Followings endpoint started.
The methodology I’m using when developing the new controllers is as follows. First, I want to get the basic infrastructure in place and the tests. That means that the first phase is to write the skeleton of the controller code, the skeleton of the RSpec tests, and to wire the two together. I make sure that the routes behave the way I think they should according to the API Spec without worrying about returns etc. The skeleton of the controller should implement all routes. The skeleton of the unit tests should be testing for happy path and reasonable error conditions. So that’s stuff like: the user passes the wrong ID for a post that they are trying to comment on, or an empty new tag to follow, etc. I then go over to the external test application and code up the corresponding code in there as well. With everything running I make sure that the endpoint is reachable from the outside (which it should be), but don’t worry about returns, processing etc. If it’s possible to setup fake returns easily I do that otherwise I just ensure the proper methods are called. After all of that is coded and committed then it is off to filling in the controller method by method. For each one coded up I complete the unit tests and the external test harness interactions as well. Once that’s all done then I move on to the next one. In some cases, like Tag Followings, there needs to be refactoring elsewhere which has implications on the above flow. I usually do those pieces before coding the controller. It is at the design time that whether I should be using common code with another controller which may not exist as a Service component becomes apparent. If I need to make any changes over in other code I check that there are unit tests which properly cover the changes I am going to make, at least as best as I can tell, write those and then make the changes. This should minimize the possibility of disruption.
When interacting with Frank R. on the merge requests one of the pieces of feedback I got was that with everything compressed down to one commit it was hard to tell why I did certain things. As I code all of that is there but I’ve been rebasing everything down to one commit per endpoint so that when it comes time to merge the API branch into the main develop the log will look something like: Post API endpoint complete, Comments API endpoint complete, etc. To get around this I’m trying a new flow. When I think something is ready to be merged i’m doing a Work in Progress (WIP) Pull Request (PR). That PR has the raw commit history and the name “WIP” in the leader of the label. After a review and a thumbs up I’m going to rebase it down to one commit and then submit the final one for integration. By the time WIP is done the code is feature complete however and should be ready to be merged. I’m therefore counting WIP PR’s as the threshold for saying something is feature complete.
With all that said the three new endpoints that were feature complete as of yesterday are: Tag Followings, Aspects, and Reshares.
After a week of distractions I finally have a new update on the progress. We’ve successfully merged all the work done to date into the one main API branch and are now working on new features moving forward. The first feature we have completed with full tests and test harness interaction is the ability to manage and work with the user’s followed tags. So we have the full post lifecycle from before, and now tags done but not merged into the main branch yet.
The merging of the various side branches into the main branch is coming along. Because this isn’t being done as a primary job there is a bit of an expected delay between the pull request (PR) being generated and the branch being merged in. This is giving me the opportunity to work on other features on Diaspora though. The process is going along much faster than I expected it to, which is good. At this point we have merged the Likes, Comments, and Post Endpoints together. The PR on the Post Endpoint is now queued up however all of those changes exist in one branch. What that means is that I was able to perform a full Post life cycle test using the test harness. This means that we have an external application talking through the API and doing the following for a user:
- Creating a post
- Querying for the post and printing out it’s data
- Adding a comment to the post
- Liking to the post
- Printing out the comments and who liked the post
- Deleting their comment on a post
- Unliking a post
- Deleting a post
This is a very important step. Follow additional progress on the API Progress Google Sheet.
It’s been a few days since I’ve been able to put some real time into Diaspora development but I’m back today. Being back home from travel too means I can finally get past the blockers on the other branches. I’ve actually gotten all of the branches I had been developing on to feature complete status, with full tests, and the test harness fully coded against it. That means that through the API one can complete the entire Post, Comment, Like, etc. lifecycle for posts with all data types (regular, Photos, Polls, location, etc). Conversations are also feature complete with full test harness as well. Streams are also complete, however I haven’t tested with sufficient post volumes to test paging behavior. Now it’s going to be the trick of getting past the tech debt of getting them merged together into the API branch. Hopefully that’ll come in the next day or two. I’m going to spend some time doing other Diaspora stuff besides that as I work through those pieces as well. As always follow the progress on the API Progress Google Sheet. After the merge I’ll be moving on to the Tags Endpoint, the first endpoint that is a full from scratch development for me.
- Fully feature complete endpoints with full external test harness interaction completed are: Comments, Conversations, Likes, Posts, and Streams (except for paging behavior).
- Ready for merging of the side branches into the main API branch
Life is actually a very short finite thing. Each day there are only so many waking hours of which one can only pour in so much energy. Do you decide to pour it all into useful work, spending time with family, spending time doing nothing but watching television or playing games, or whatever. The bottom line is that we have to decide how we want to expend that in a way that will make us as contented as we can be. We will miss the mark obviously but that doesn’t mean that one has to engage in behaviors that they know are moving opposite that direction.
Continue reading Personal Reminder: no one has a right to your time
I’ve had my moments in the past where Facebook pissed me off and I tried Google+. That didn’t work out too well so I went back to Facebook after they addressed some of those problems. I had my moments in the past where I was concerned about the amount of tracking Google does in searches so I went to DuckDuckGo. That’s still my main search engine but sometimes I need results that come out better in Google so go there. I also use the Google platform for my e-mail, documents, etc. The concept of them selling my data in exchange for giving me free service has bothered me to varying degrees over the years, but seeing how greedily it was manipulated recently is really amping that up to me. The amount of information available to the highest bidder has always been a known quantity to me but these recent stories are just putting that up to eleven. It’s not just the Cambridge Analytica story. There is also the story about Facebook and other companies forcing users to turn over their keys, so to speak, so they can look at any and all their personal data as a condition for working for them. There is the way they exploited that data in difficult discussions.
Continue reading Replacing Facebook/Google Et Al With Open Platforms
Like many people I got into my software development stack rut; complaining about the things I hated about it and why I wanted to change. The Java stack had been treating me ever increasingly well, especially with the refactoring of Spring into what it is today, but the language itself and it’s stagnation bothered me and had me starting to gaze at .NET now that it’s open source. I am now officially done with that exploration and will be sticking with the JVM-based system for the time being. This is driven by three major things: Kotlin, JavaFX, and the fully open source nature of the pieces I use.
Continue reading Kotlin, JavaFX, and OpenJDK Is My Perfect Dev Baseline
As much as I’ve never been a fan of Unity I’ve learned not to hate it as much as my host OS (and even in some of my VMs). Sure, my go-to desktops of late are mostly MATE distros or Cinnamon, but Unity hasn’t been completely unacceptable. With Ubuntu’s recent announcement of the demise of Unity and people openly pontificating on if this means Ubuntu is abandoning the desktop or looking to sell to someone like Microsoft who will then kill it on the desktop I started to analyze what this meant to me as a Linux desktop user. Is this the end of the road for that journey and therefore back to Mac or, god forbid, Windows?
Continue reading Existential Angst From Ubuntu Desktop Demise
Over on Slashdot there is an article about an IP saga of sorts between Wix and the makers of WordPress. While the Slashdot title accuses Wix of “stealing” code, not even WordPress’s Matt Mullenweg accused him of that in the original post. What happened is pretty simple. The Wix engineers decided to wrap a WordPress rich text control so it would work well with React Native. The Wix engineers made that project under an MIT license and then dutifully used it in their proprietary iOS application. The WordPress control they wrapped was licensed under GPL, and that is where the problem is.
Continue reading Wix/WordPress Argument Shows Viral Nature of GPL