Diaspora API Dev Progress Report 17

The last couple of days has been a lot of heavy effort of slogging through some ever increasingly complex changes to get the API going.  I started with what I thought was going to have a relatively easy time with the notifications however the deeper I went into the more I realized that I either had to come up with some relatively (for me anyway) complex queries to populate some of the return types or I have to settle for some N+1 type query behaviors.  “N+1 queries” are one where you pull the results one piece at a time.  That’s fine for smaller data sets, like five or ten or something, but if you are dealing with hundreds of entries you are really thrashing your system.   So I got about half way through the notifications API and then put it on the shelf and moved on to the API was dreading the most: Photos.

I was really psyching myself out about having to deal with the whole image file upload part of the Photos API and then the subsequent tie in with the Posts API.  It shouldn’t be that complicated but these are things I had never done in Rails or with the Kotlin Fuel framework.  How would they interact?  How difficult would the security checks be?  You get the idea.  It did take several hours of figuring out what the current controller is doing and then how I wanted to refactor the more complicated operations into a service but I got there.  Once I had that I had to test the whole aspect of limited posts et cetera, which I hadn’t done as well as I had thought previously.  Thankfully my Ruby unit tests were solid I just had some hiccups in my test harness.

At the end of the day we have the Photos API and the Posts API working with the photos perfectly, to the point where I was able to make a fully populated post including with an image that was uploaded externally as well.  That means I’m going to jump back on the Notifications API to wrap that up and all that’s left is the Search API.

In summary:

  • Partial Progress on the Notifications API but shelved to figure out queries later
  • Posts API is feature compleet with full tests
  • Was able to create an entirely populated post with the respective images from scratch using an external application for the first time ever in Diaspora (see this post)
  • 1.5 Endpoints left to go to be feature complete

Diaspora API First: A Full Externally Created Post

After slogging away for most of today on the Photos API, with lots of needing to understand how things work and a couple more tweaks before it was ready, I decided to celebrate by showing the ultimate progress report: a screenshot.  What is so special about this screenshot?  It is the first post in Diaspora that has been fully made by an external application.  The “external application” in this case is a test harness written in Kotlin which is designed around the API spec.  This test harness first uploaded the image file, then it created the post with every feature a post can have including: location, polls, and references to other users.  The post was written by a “user3” (for testing might as well stick to simple names).  This is a screenshot from user1’s perspective.  Notice that they also got the expected notification.  Yes it’s still a bit of a ways from done but it’s still a great milestone, so I’d say it’s time to celebrate for a bit before getting back to it :).

Diaspora API Dev Progress Report 16

Brief update from today on the Diaspora API development progress:

  • On the Users API turns out we probably still want to have the contacts endpoint if only for the primary user since the Contacts API works on a per-aspect level the way it is mapped.  Whether that method shows up in Contacts API at a different mapping or on the User itself is still TBD but it will be a change to the spec.
  • The Post Interactions API is feature complete with full tests and the completed test harness.
  • Work has begun on the Notifications API.  This is the first change I’ve done that will require a DB migration, adding a new GUID column to notifications, so this is going to take a bit longer for me to complete as I do background research on that.

At this point it’s actually easier to look at what is left to do versus what we have done (which is a huge plus sign):

  • The only two endpoints that haven’t been touched are Photos and Search. Once these are done (along with work on Notifications) the entire API spec will have been implemented.
  • Implement a new poll interaction method for answering a poll through the API
  • We need to implement paging on several of the endpoints.  This technique will be similar to how it’s done in the core controllers but it has to be different because the return type needs to have the next/previous pages and the corresponding format needs to honor that.  The actual mechanics of the queries are pretty much the same though so grafting them into the existing feature complete controllers should be relatively easy.
  • Right now the OpenID integration works well enough for testing but it currently requires revalidating the app every 24 hours.  This has to be tweaked to be more reasonable.  There may be some refactoring in there as well.
  • The Posts API Endpoint accepts any photos currently, including those that are already attached to another post.  This is not consistent behavior and has to be corrected to only allow a “pending” photo to be added.
  • Sweep of all of the APIs for consistency on security, service initialization (where appropriate), params parsing idioms, etc.
  • Sweep through the unit tests to make sure that edge cases are covered in the same way
  • Documentation updates to account for things discovered during the development (error codes added, format tweaks etc.)

Diaspora API Dev Progress Report 15

It’s been two weeks since my last Diaspora API Dev Progress report but that’s not because nothing has been going on.  Between the RubyConf 2018 attendance last week and this week being a holiday week there was definitely a drop off in how much development time I put into Diaspora, and therefore mostly into the API.  However over that time there has been some development progress:

  • All of the previous work has been successfully merged down into the main API branch.
  • The Contacts API is feature complete with full tests and the completed test harness
  • The Users API is feature complete with full tests and test harness with the exception of the User Contacts API method.  That method was supposed to be able to return another user’s contacts if that user allowed that.  However that feature no longer exists in Diaspora so I believe it is extraneous.  If that’s agreed upon then this is feature complete and ready to go.

This week I should be able to apply a lot more development effort than I have been able to the past couple of weeks.  Hopefully that translates into forward progress on some more endpoints.  The trend seems to be that they are getting more difficult to knock out so my velocity is slowing.  I guess it’s better than being stymied in the beginning.

MacBook or XPS Linux Ultrabook…looks like a Mac after all

I have had two laptops for most of the twenty years: a personal laptop and a work laptop.  Before I owned my own company that was a question of the company’s I worked for policies.  While I had my own company it was about living by the same rules that applied to everyone else in the company (I’m a big fan of dogfooding anything I do).  Now that I’m on the individual consulting/developer bandwagon I’m in the same boat.  I have a pretty decent System76 Linux laptop that’s a couple years old but pretty bulky.  I have a positively ancient 2011 MacBook Air.  Disk space and speed wise it is fine.  Memory wise at 4 GB it’s starting to get a little cramped if I have too many Google Drive tabs open and the like.  Processor wise though it is a dog.  It’s at the point now where some sites like Facebook and Gmail can take tens of seconds to complete rendering.  At least they allow interactions while they finish parsing their JavaScript etc.

When the MacBook Pros came out it looked like that’d be a great opportunity to switch and while the feature set finally looked reasonable the price point for what I want was artifically high due to selections that I couldn’t get with other configurations.  It’s not that a particular end configuration was expensive compared to a Dell (or System76) but the fact I could get the exact configuration I wanted out of the Linux laptop and not the Apple made the actual price point lower by over $1000.  With the new MacBook Air models that just came out I decided to do my standard configuration.  For this one I’m doing a 13″ to replace my MacBook Air but with the reasonable bump ups to make it last a long time.  After all, I like to keep hardware for awhile so no reason to skimp out to have to replace it yet again in a couple years.

What were the end results?  When I put together the exact configuration I’m looking for in both systems the Mac comes out to $1599 compared to $1659 for the Dell.  That’s pretty astounding to me.  I finally have a Mac option that fits my need at essentially the same price point.  What does that mean?  First, it means that the imminent demise of my antique personal laptop is imminent.  Second, it means that it’s probably getting replaced with another Mac.

Diaspora API Dev Progress Report 14

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.

Diaspora API Dev Progress Report 13

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.

 

Diaspora API Dev Progress Report 12

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:

  1. Creating a post
  2. Querying for the post and printing out it’s data
  3. Adding a comment to the post
  4. Liking to the post
  5. Printing out the comments and who liked the post
  6. Deleting their comment on a post
  7. Unliking a post
  8. Deleting a post

This is a very important step. Follow additional progress on the API Progress Google Sheet.

Diaspora API Dev Progress Report 11

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.

In Summary:

  • 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

Personal Reminder: no one has a right to your time

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

Exploring Longvetity and Software from a 1st person point of view