Gastric Sleeve Two Years On

I am coming up on almost 3 years since I have had my Gastric Sleeve weight loss surgery.  Some people might wonder how I am doing and how does the long term look like for someone with the surgery.  Well, the news is good.  I updated everyone that seven months on, I was approaching my target weight of 195 lbs (13st 13 lbs/88.5 kg), well I met that and then exceeded that by about another two pounds, reaching my lowest point of 193 lbs.

Over the next 18 months or so, I started to slowly creep back up, eventually reaching about 215 lbs (15st 5lbs/97.5 kg).  Lot of this was due to my lifestyle at the time, which was pretty sedentary and the “enjoyment” of simply not worrying about how much I ate.  This was my new natural weight.  But even then it did start to bother me that I was starting to not fit some of my shirts and trousers.

I was lucky, in that I had been working full time in Scotland but in August of this year, relocated back to London for work.  The simple fact of being back in London and having to walk around, as well as being back day to day with my partner has let me focus on being more active and eating a little bit better.  That has quickly returned me to 195 lbs.

The challenge when I reached 195 lbs before was that I didn’t look healthy.  My family in the States, when they saw me around that weight thought I looked “ill”.  I think in a lot of ways it was my body getting used to that weight.  Two years on, and hitting that milestone again,

My appetite has increased after the surgery, but I am still not able to eat what most people would consider a “normal” sized meal.  Although I don’t directly pay attention to what I eat specifically, I find that my subconscious mind goes for the softer foods.  Really the only thing that really gives me too much issue are large amounts of dry and fibrous foods.  I also struggle sometimes, getting quite hungry now, of my eyes being far larger than my stomach.  Again, getting used to not eating everything you are served in a restaurant is something you have to get used to.  I am lucky again in that my partner has a very very high metabolism and is a marathon runner, so my leftovers are quickly absorbed.  We really enjoy meals like tapas and dim-sum, which allow each of us to eat each at our own pace, share in the meal and have a variety of foods.  That more than anything is something I value, the variety.  I would rather have a couple bites from several dishes then try to eat one thing.

Being honest, constipation is a bit of a battle for me.  I seem to go into bouts where I will get heavily constipated and times where I don’t, though my diet doesn’t change in a way I am aware of, though my bowel movements have never returned to a state before I had the surgery.

The other long term downside that I suspect is related to the surgery is that my face has developed an exceedingly dry skin, which is often flakey and itchy.  I take religiously a multi-vitamin and oil supplements as well as wash my face daily with hypoallergenic products and use a moisturiser, but generally, I can’t seem to fully deal with the issue.   My partner has said I should really see a doctor, which maybe I should.

Even with the two “downsides”, feeling far more healthy, being more active, and not standing out in society for the wrong reasons make the decision to have the surgery the best decision for myself I have ever made.  While a gastric sleeve surgery may not be for everyone, it clearly works for some really well.  I couldn’t have expected a better outcome.

Marriage Equality, Finally

Yesterday I was in tears, in the office.

Kit and Simon
Kit and Simon

Simon and I met each other in 1999 and started our relationship in 2000.  We struggled for a number of years trying to settle down and started to realise that was difficult for bi-national same gendered couples.  We spent a few years living in limbo between North America and Europe.  We had decided that we would try to find a way to move to the US.  We were respecting the immigration laws of the US and realised that it was an uphill battle, but eventually US ICE decided that Simon didn’t belong in the US and denied him entry.  Our friends and family were shocked that this could happen.  They encouraged us to fight it, but we knew, really knew, that there was nothing we could do, that the Federal government was barred, legally, from recognising us.

In 2005, the UK made the bold step of allowing Civil Partnerships.  This presented a unique opportunity for US.  I knew my skills were portable enough for me to find work in the UK and the UK had been Simon’s home for most of his life.  It wasn’t originally first choice, but it would do.  So I started through the motions of immigrating to the UK.  I ended up conversing with the entry clearance officer who issued my proposed Civil Partnership visa a few year later (as I become involved in immigration rights in the UK) and he told me that I was the first Civil Partnership visa he had every issued, in the Summer of 2006.  He was quite happy to find out that things had worked out for myself and Simon.  In November 2006, I moved to London.

About two years ago, Simon and myself realised that we wanted to change our lives.  We realised, after many many many years of debate that we wanted a family.  We also weren’t in a personal situation which would allow us to raise a family, with my work being in Scotland and Simon’s work being in London, it wasn’t the life we had envisioned for ourselves.  So were decided to move.  We looked all over the world and settled on Vancouver.  In part because we knew the US was simply not an option for us.  We started down the process of finding a way to get that accomplished.  We accidentally found the best immigration lawyer in Canada, I suspect, named Marina Sedai.  But with everyone’s best intentions we realised that we couldn’t get the immigration process in Canada to match our desired timelines.

This last month, as the stark reality that the timelines for Canada immigration weren’t viable, we resigned ourselves to what we called “Plan B” which was to settle down in London for the next 18-24 months while we started the family and then hopefully the Canada process would catch up with us by then.

I had been closely watching the Supreme Court on DOMA and Proposition 8.  I followed the arguments with rapt attention.  I had always admired the US Supreme Court and while it may not always get things right, it gets far more right then it gets wrong.  I knew, that if the US was to ever become a viable option for Simon and myself, DOMA needed to be struck down.  I also realised that based on the US Constitution and how the Supreme Court operates, that they would likely strike it down, unless they sidestepped the issue on jurisdictional grounds.  In the end, the what I wanted and what I expected merged.

While this won’t be straight forward, and Simon and I never wanted or asked to be trail blazers, we suspect that, as we progress with our family plans, we will find a way to move to the US, now that the US Supreme Court has made it clear, if a State determines we are married, then the Federal government has to respect that determination and extend the same rights and benefits.  After 13 years of frustration, I can finally say again that I am proud to be an American.

Marriage Equality

Being “gay” does not dominate my life and I don’t often think about being “gay”. I do often thing of my civil partner, Simon, much as I would assume any married couple would. As I have mentioned before, after about 6 years of being in a relationship with Simon, I moved to the UK in 2006, in large part, to take advantage of the recent civil partnership laws that were created. Simon and I entered a civil partnership in 2006 and in 2013 will be celebrating 13 years as a “couple”.

Myself and my partner at a family event.
Myself and my partner at a family event.

For the most part, we just get on with our lives, as an “traditional” couple would. As we approach our middle ages, we realised that we had reached the point where we could make a choice about us and potentially family, instead of careers. We both have very well paid jobs and have been very successful, but we know there is more to life than just work. So a couple of years ago we put the wheels in motion to change our lives. Being of sufficient means, we knew we could go a lot of places in the world. We short listed 7 cities across the globe and assessed each one. Sadly, no US city made our short list. That isn’t because we have anything against the US. Being an American, there is still a big part of me the longs for the US and Simon also sees lots of advantages of the States. But the land of my birth has chosen to not recognise my relationship with Simon. Even if we both were US citizens, there would be 50 different versions of what our relationship meant, which means we would have to be very careful about where we lived in the US.

While the Supreme Court this week is hearing arguments on Proposition 8 and DOMA, there is far more at stake for Simon and myself than I think we would like to admit. While our immediate plans are to move to Vancouver, as Simon has been accepted at UBC and I am sure we will like Canada, neither of us is Canadian and therefore we don’t have a “right” to settle in Canada, though it may very well be possible. We would like to be in a situation where at least my country of birth is an option and that we don’t feel like exiles.

I know the Supreme Court, rightfully so, is far more concerned about keeping a balance between the Federal Government and States rights, but they also look after us as individual rights, and I as a US Citizen am being denied my birthright to pursue happiness. If there are Federal benefits that are extended to traditional married couples, they should be extended to me, including immigration benefits, irrespective of whatever definition the State puts to similar laws.

Having been used to being treated equally under the law for the past 6 years, it is something that I am unwilling to give up, and anyone who knows Simon or myself wouldn’t demand that of us.

Dojo 2.0

I have been working on a few things which I will be trying to campaign for as being part of Dojo 2.0. Almost everything I have been working on is included in my d2-proto GitHub repository. I want to cover off some off some of my thinking.

Object Composition

declare has been the foundation of the “class” structure of Dojo. I know Eugene has developed dcl, which is the successor to declare, but one of things that I think declare doesn’t do is actually embrace JavaScript and its prototyping based language with constructor functions. Instead it tries to take the path of classical OOP inheritance.

The first challenge with this is that it leads to confusion among those developers coming from other languages. I remember recently having a debate with a developer trying to figure out how to create static methods in Dojo/JavaScript.

Something that I think embraces the concepts of prototypes and constructor functions is Kris Zyp’s ComposeJS. It provides a way to “compose” prototypes and constructor functions. It also leverages the concepts of Aspect Oriented Programming that have heavily leveraged in “modern” Dojo, in particular the join point advice.

I have brought that into my Dojo 2.0 repository and have added an important key element in my mind, in embracing ES5 property descriptors. By using the compose.property() decorator, you can generate ES5 properties in your prototypes:

In addition the accessor descriptors understand the other decorators, like the AOP ones of compose.before(), compose.around() and compose.after() to be able to provide very feature rich direct property access while not requiring discreet property accessors like the current Dojo/Dijit .get() and .set().

Object Observation

In Dojo 1.5 dojo/Stateful was added, which was a core module that provided the concept of discreet accessors and the ability to “watch” properties for changes. .watch() was a debugging concept added to SpiderMonkey (Mozilla/Firefox) to allow a level of debugging and never became mainstream. dojo/Stateful adopted this. The concept is very useful, to know when a property changes and do something about it. Now, ES5 properties deal with the ability to allow direct property access, they don’t necessarily provide a easy way to actually observe changes to your properties, for key concepts like data binding.

ES6 has the Harmony project, which part of it is specifying Object.observe() which provides in native code this feature of being able to observe changes to objects. Of course waiting around for ES6 and Object.observe() is untenable for most. So in order to solve this problem for now in Dojo 2.0, I have developed a new foundation module named Observable which tries to provide a very similar API to that of Object.observe() but only leveraging ES5 features. It should be possible to offload this to the native API when generally available.

DOM Manipulation

Within the committers, there has been a fair amount of debate around the direction of DOM manipulation in Dojo 2.0. The current thinking is to potentially adopt JQuery 2.0 as the DOM manipulation engine of Dojo 2.0, or to rewrite/refactor the existing DOM manipulation modules. There is also some who think that Kris Zyp’s put-selector is worth consideration. I wanted to understand more about put-selector and so I brought it into my repository as put. Once I got my hands on it, I was impressed with it. For those not familiar with it, it leverages the concepts of CSS selectors to perform DOM manipulation. Instead of having a complex API to create, modify, move and place DOM nodes and structure, you simply use the one function of put. You likely have been using one form or another of CSS selectors to select your DOM, which are the core of both JQuery and dojo/query, so why not extend that paradigm to DOM creation and manipulation?

There are those who are familiar with it who feel that its concise syntax can easily lead to abuse and confusing code. This is potentially true, but like all powerful tools, they can be misused. This is true of RegExp, which can easily lead to confusing code, but they solve complex problems much quicker. My biggest argument is that DOM selection requires a good grounding in CSS selectors, so why not build on that knowledge? Developer’s being aware that other people may read their code is far more important than hobbling people by dumbing down their tools. A good developer should document their RegExp just as well as they document their selectors.

Declarative Syntax

As many of the Dojo committers know I am a huge supporter of having functional parity between JavaScript and the Dojo declarative syntax. The declarative syntax is one of the main reasons I was drawn to Dojo in the first place. While I don’t use it personally anymore, I have quite a lot of interest in the dojo/parser which drives the declarative syntax. Some of my first significant contributions to Dojo are around the parser.

So of course I couldn’t pass up the opportunity to provide a new parser as a candidate for Dojo 2.0. From an API perspective is is very similar to the current dojo/parser and has the same features, but it wholly drops the legacy of the current parser. Also, it is designed to be a “speed demon”. My tests indicate for certain tests it is about twice as fast as the current parser and is even 20% faster than the dojox/mobile/parser which was specifically designed to be efficient on mobile devices.

It still needs additional work, but my hope is that there will be only a single parser for Dojo 2.0, once that is as lightweight and performant as possible for mobile, provides only what is needed for complex templating and is as feature rich for desktop applications. It might even be possible with dojo/has to provide opportunities to built code that is tailored to the environment.

Widgets

With, in my opinion, two of the core parts of the toolkit being different in Dojo 2.0, it sort of calls for a different path with widgets. If object composition and DOM manipulation change, there is an opportunity to take a look further. Dijit has been a great strength of Dojo. Again, it was one of the reasons that I was drawn to Dojo in the first place, because I wanted a JavaScript toolkit and a widget framework as “one”. When I was looking around in 2008, there were very few that combined the two well, if at all.

But in my opinion, time has marched on. Dijit has become solid, feature complete, but also relatively feature static, because the number of people and organisations that have built on it. It is now almost impossible to make a significant improvement in Dijit without causing havoc somewhere else downstream. People need that dependability and stability though. There is a lot of good in Dijit, a lot.

While I understood how to create my own Dijit based widgets, I will admit I didn’t understand deeply the underpinnings of Dijit and widgets in general. Therefore I wanted to see if I could create a widget based on compose and put. I have created a very rough Widget base module based on this. This gave me enough to think about.

What is clear to me now is that while there needs to potentially be a Dijit 2.0 that works off Dojo Core 2.0, there needs to be another widget system as part of the eco-system that can start afresh, being informed by Dijit but being unleashed from the “shackles” of the Dijit 1.X legacy. I think there are some key points that a new widget system needs to address:

  • Isomorphism – The concept that the widget shouldn’t care about where it is rendered.  As server side JavaScript continues to mature and there are constraints on the speed and power of mobile devices, isomorphism becomes even more important.  One of the aspects of put is that it can render DOM strings without the need of the likes of esprima.  It is quite conceivable isomorphism is achievable without too much work.
  • Data Binding – Some additional solutions have been added to Dojo to solve this problem, like dojox/mvc, but ultimately I think that data binding is something that should be built into the core of a widget framework, instead of an adjunct.  While Dijit has always been able to read from a data store to populate things like select lists, it hasn’t been as robust in being to update records and state based on binding to underlying data.
  • Responsive – “Modern” widgets need to be built from their foundations to meet responsive design.  Right now, the current solution is to touch enable Dijit and then develop dojox/mobile.  And while there has been a lot of work between dojox/mobile and Dijit, they are essentially two different projects with dojox/mobile being built ontop of some of the foundation of Dijit.  The need to have efficient code on the mobile platforms has led to a significant “fracturing” of the bases of Dijit to maintain the two different sets of widgets.  The current framework also lacks any specific API features that allow developers to build responsive widgets.  A new framework should build this into its foundations.
  • Bundling of all 3 Technologies – Widgets are not just JavaScript objects with a DOM structure.  There is a 3rd technology that is often relegated as a 2nd class citizen, that being CSS.  Visual presentation and theming.  To me, this has always felt slightly disconnected and there is no easy way of “bundling” or even “unbundling” the necessary CSS to run a widget in the current Dijit framework.  There is no way for a widget to ensure its styling is loaded, nor a way to encapsulate it, so it can be composited into a “built” widget.

There maybe other key factors in widgets for Dojo 2.0, but in my mind these are the key things at the moment we don’t have a ready answer for.

Packaging, Wrap and Toolchain

One of the main areas that I first expressed a lot of my thinking for Dojo 2.0 was in the area of packaging, wrap and toolchain. It is the areas where my thoughts were the most mature. As far as packaging, I laid out my thoughts as well as took a lot of feedback from others in the Dojo 2.0 Packages and Distributions. From a toolchain perspective, I laid out my thoughts about package management, again with lots of feedback in Dojo Toolkit 2.0 Package Management. There is more, but probably best left to a future post or discussion!

In Conclusion

As always, these thoughts are my own, they don’t represent the way Dojo 2.0 will go, but they lay out my thinking and will form the foundation of what I will “campaign” for in Dojo 2.0. I always have always said, I would look into the items I was interested in instead of trying to “boil the ocean”. I may pickup more items that are of interest to me as we get further down the road to Dojo 2.0. The biggest thing I would like to do though is encourage (provoke?) others to start making their case for Dojo 2.0.

ES5 Accessor Properties

I have been messing around this weekend with Object.defineProperty and realising some unanticipated behaviour when using accessor properties and prototype inheritance. Essentially it boils down to this, accessor properties are only ever owned by the Object they are defined on.

For example, if I were to do the following:

Now I hadn’t actually expected that. So you have a choice, in your constructor function, you can iterate through your prototype, looking for accessor properties and copy the property descriptor directly on the instance, or you can leave well enough alone.

Dojo and Node

Using client side JavaScript frameworks on server side NodeJS? “Crazy…” I can hear you mumble to yourself.  Well, I tend to disagree.

The biggest advantage, is that you have already merged your language both client and server, so why not merge your coding style?  Having less of the basics to remember is always a good thing.  It lets you focus on being more productive.  I have been working on a project for a while, and one of my personal requirements was to make it as Dojo like as possible.  Mainly as an experiment, but also to learn how “challenging” it would be.  In this post, I want to share with you some of the lessons I have learned.

My opinion, as well as others, is that CommonJS and Node abandoned AMD because “we don’t care about browser user agents” and while that sort of posturing is maybe self-gratifying, it leaves those who don’t have the luxury of just coding for the backend frustrated and confused.  Some may consider it a religious argument, but there is little overhead and nothing “bad” about AMD running server side.  Certainly there are some aspects of AMD that aren’t needed under server side JavaScript, but the only real “issue” is that generally you are a little more structured with your modules (woah, organisation and structure, I know, we can’t really have that going on).

Bootstrapping

The first thing you would need to do is bootstrap an AMD module loader.  There is some good information on using RequireJS under Node (including information on how to define AMD modules to work without an AMD loader under Node), but the Dojo Loader is my loader of choice.  So a basic sort of bootstrap would look like this:

This of course assumes that your Dojo installation is located in the ./src directory along with your custom modules located in ./src/app.  This of course will only load the Dojo Loader and nothing else, which would be a very boring application.  What I usually do is specify a root module, which then does whatever is needed by my application.  For example:

And now we just need an AMD module to load.  Your main module could either be an AMD require() or AMD define().  I won’t go into the subtleties of these two, but usually your main “block” of code should be a require(), but you should note that relative MIDs don’t work with the standard require(), but need the context sensitive require().

I usually name my “bootstrap” code server.js and place it in the root of my project.  Then all you need to do from the command prompt is:

Loading AMD Modules

Well, this is simple. Assuming your package map in your config was accurate, you just load modules to your hearts content. So maybe we want to create a module that creates a “deferred/promise” based timeout named wait.js:

And then to use the module, we update our main.js:

Loading Node Modules

You might be saying “oh, this is great, but I have this Node module I want to use, and you replaced my require() with this AMD stuff.”  The good thing is that with Dojo 1.8, a new plugin module was included named dojo/node.  This module will allow you load a regular Node module.  For example, if we wanted to load a file:

dojo/node resolves modules in exactly the same way the Node native require() does, which is relative to where you loaded the the Dojo Loader.  So that means it will look in ./node_modules for local modules if bootstrapped the loader from the ./server.js.

The Dojo Way

Now that you are loading Dojo and other AMD modules, you might be feeling a bit more comfortable. One of great things about Node is that it is non-blocking and most of the APIs are designed to run asynchronously, which in a lot of ways is the Dojo way. The thing that will smack you in the face though is the propensity for Node like APIs to use callbacks instead of a promise based architecture to provide this asynchronous type of programming. I personally just even hate the way the code works, calling a callback calling with an err argument as the first argument and then any result arguments after that.

When I started doing a lot with Node, I first just tried to adopt the style, but really started getting frustrated, especially when having long chains of asynchronous functionality and I quickly longed for the day of Dojo Deferreds, so I started writing functions to provide the promise interface.

Doing so is relatively straight forward, let’s for example, create a module that provides the Node fs.readFile as a promise based call.  To start off, a Node style code block would look like:

Now let’s create an AMD module, based on Dojo Deferred, that provides this API:

Then we need to use our new module:

Now that feels significantly more “Dojo like”. Of course you could spend all day wrapping functions, which is why I created setten. While it is still early days (and in writing this article I have realised some benefits I could provide) it is available to make your Node code more “Dojo like”. I know there are other libraries out there that deliver a promise based system for Node, but I am not aware of any that are based off of the Dojo Promise API.

Other Thoughts

I will admit I am still learning every day on how to get Dojo and Node working well together, but I am pretty happy with the results. I am also finding that a fair few of the libraries out there provide CommonJS and AMD module support and those are even easier to integrate. What is great about libraries that support AMD is that you have even more seamless experience between the server and the browser user agent.

One of the early mistakes I did was trying to keep my server-side modules as a “sub-package” of my main package where I would keep shared or client only modules.  The problem becomes when you go to build your client code for deployment, having all your server code mixed in isn’t so good.  So I usually end up with three AMD packages in my ./src directory, which would be something like:

  • ./src/app-server – Server Only Modules
  • ./src/app-client – Client Only Modules
  • ./src/app – Shared Modules

Another thing, which I mentioned briefly above, is that your working directory for all of your code is the path where you invoked the node binary. So, if you are dealing with paths for files, even in modules buried in packages somewhere, remember what your working directory is.  Relative define() paths work as the Dojo Loader figures out the absolute path based on the configuration.

I have four main projects that are build around Dojo on Node.  They are in various states of development and were done at various times of my “learning” of how best to do Dojo on Node, but they maybe able to give you some ideas:

  • dote – A open collaboration forum
  • dojoment – A markdown based documentation wiki
  • doscuss – A community discussion/support forum
  • kitsonkelly.com – My personal website

Future

One of the things I want to play with at some point in the future is using Dojo DOM modules against the jsdom package.  James Thomas has done a server_side_dijit project, so it does work, but I haven’t tried myself yet.

I have yet to find any significant disadvantages or limitations with using Dojo server side, and like I said at the start, it is a lot easier to have to deal with just one style of coding and since Node style of coding doesn’t work client side, why not do Dojo-style coding server side?

Equality versus Fairness

Being an American expatriate, especially living in the United Kingdom, gives a particular perspective on US society.  I think this is highlighted during the Presidential election, when you see Americans en masse struggle with the concepts of equality and fairness.

Equality and fairness or concepts that are easily confused.  Especially because one of the main tenants that the United States was founded on was equality, it is easy for that to be muddled with the concept of fairness.  My opinion though is the aggrieved, both liberal and conservative, are arguing about fairness.  Equality means everyone, no matter what, is treated in the same way by the government and society.  Ultimately Americans don’t want this.  This is actually a far more French concept, where muslims are made to remove their religious garments in order to ensure equality.  It is manifest in Northern European governments and societies, where people are taxed into equality by the government.  Americans don’t want that.  A land of opportunity cannot survive on equality.

Fairness on the other hand, is that people are treated consistently and in line with the merit of their actions.  This is what Americans are really getting at.  It is what is driving the concern about the 1%, feeling that somehow the 1% were able to get a special “member’s only” pass.  The right argue that if people don’t work, they shouldn’t get money from the government.  Again, fairness at the root of it all.

In the UK, while equality and fairness are often confused, it is fairness that bubbles to the top.  People, consciously or unconsciously get upset when the rules of fairness are broken.  Fairness is far more important than equality in the UK.  The political parties mention it in their rhetoric and policy often enshrines this, versus equality.  Equality is presumed to a degree, but fairness will trump equality every time.

In the current Presidential election, I think it is generally unstated, but the main driving factors behind who will vote for which candiate is actually far more about their perceived fairness than anything else.  Those voting for Romney will do so because they believe “hard work” will be treated fairly, and if you have been successful, you will be protected and not treated unfairly.  Those voting for Obama believe that a large portion of the population haven’t been historically treated fairly and haven’t had the right opportunities to take advantage of and see that Obama will continue to protect those at the cost of those who can afford it.  Both sides believe the other candidate will treat a segment of society unfairly.

If we were to move our dialogue to better articulate fairness, to better understand what is really important to us, then we might actually move forward the conversation.