Saturday, February 09, 2013

The Prodigal Son


A friend and I recently had a conversation about applications of the parable of the Prodigal Son in our lives (see her post) and it got me thinking on several points on the interpretation of this parable.

When asked about the interpretation of this parable, Joseph Smith taught "I have a key by which I understand the scriptures. I enquire, what was the question which drew out the answer, or caused Jesus to utter the parable?" (Teachings of the Prophet Joseph Smith, pg 277).  The Pharisees were criticizing Christ for sitting with sinners.  He then taught several parables regarding the rejoicing over those who repent.

The parable of the Prodigal Son stands out to us among those because we get a more intimate look into their lives.

One lesson we gain by this more intimate look is that there is not just rejoicing over a lost child of God but that in their journey back they can and should aim high.  The prodigal son came back only aiming for telestial, maybe terrestrial, glory in asking to be a servant (see D&C 76:112).  The father told his son to set his sights higher, to that of the celestial kingdom, by acknowledging their kinship (see D&C 76:56-58).

Another lesson is from the Other Son.  We get the reminder to not be jealous of the rejoicing for the returned sinner (see Elder Holland, The Other Prodigal.  There is sadly a tendency though to over-analyze this son since those who would do such analysis probably see more of themself in this son than the prodigal son.  Within the overall context of the parable, one might try to make the Other Son a surrogate for the Pharisees.  President Kimball warned against being overly harsh in judging the Other Son and taught that it is better to have not sinned than to have sinned and repented (Spencer W Kimball, Miracle of Forgiveness, Chapter 20).

Focusing too much on the Other Son loses our focus on what the focus of this parable is (rejoicing when sinners repent and come back).  We end up incessantly playing a single note tune similar to the pitfall of gospel hobbies which Elder Packer warned about:

Some members of the Church who should know better pick out a hobby key or two and tap them incessantly, to the irritation of those around them. They can dull their own spiritual sensitivities. They lose track that there is a fulness of the gospel, . . . [which they reject] in preference to a favorite note. This becomes exaggerated and distorted, leading them away into apostasy.

Reading the Other Son's words in context of the teaching setting, he seems to be there to fulfill the role of an "audience surrogate" (WARNING: TV Tropes) so we gain an understanding of the father's thoughts.  This doesn't diminish the opportunity to learn from the Other Son but it puts it in context to not look beyond the mark.

Analogies break down after a certain point and looking past that can lead to a skewed perspective on the gospel.  We don't see is what happens to the Prodigal Son in the long run.  The truth being taught has been covered.  We can extrapolate a couple of possibilities based on gospel truths we already know.

The first is the more sad to contemplate intepretation.  The Prodigal Son returned to the presence of his father but with his inheritance wasted much as David had fallen from his exaltation (see D&C 132:39).  I think its much better to contemplate on the interpretation that I would hope would be more broadly applicable and with much less dire results.  This interpretation ends right where Christ does.  Unlike an inheritance from an earthly father, the inheritance from our Heavenly Father is not zero-sum, to give to one son does not diminish from another.  There is infinitely more to dole out to those who squandered but repent.  There is hope for something unfathomably great for those who repent.

Monday, January 14, 2013

Giving in Life



For whosoever will save his life shall lose it: and whosoever will lose his life for my sake shall find it.
I've been contemplating this principle since a talk given in church a while ago.  One specific point he brought up is the classic idea that we shouldn't cast blame on the teacher for not getting anything out of a class.  "What do I get?" is the wrong question, the wrong perspective.  We should have the perspective of "What do I give?".  It is amazing how much we grow when we aren't seeking our own growth but those around us.  In my studies recently I've come across this principle regarding multiple topics.

Regarding this topic, Marion G Romney said

We lose our life by serving and lifting others. By so doing we experience the only true and lasting happiness. Service is not something we endure on this earth so we can earn the right to live in the celestial kingdom. Service is the very fiber of which an exalted life in the celestial kingdom is made.
Knowing that service is what gives our Father in Heaven fulfillment, and knowing that we want to be where He is and as He is, why must we be commanded to serve one another? Oh, for the glorious day when these things all come naturally because of the purity of our hearts. In that day there will be no need for a commandment because we will have experienced for ourselves that we are truly happy only when we are engaged in unselfish service.
Below are quotes that explore this concept applied to specific principles.

Sacrifice
President Gordon B. Hinckley explained: “As we look with love and gratitude to God, and as we serve others with no apparent recompense for ourselves, there will come a greater sense of service toward our fellow human beings, less thinking of self and more reaching out to others. This principle of love is the basic essence of goodness” ( Standing for Something, 9).
I have thought of this often and have reached the conviction that in a strange way those who have are actually dependent upon those who have not. Something spiritual happens to a person when he reaches out to help someone else.
As givers gain control of their desires and properly see other needs in light of their own wants, then the powers of the gospel are released in their lives. They learn that by living the great law of consecration they insure not only temporal salvation but also spiritual sanctification

Discipleship
It is not only important for the growth of the members involved to exercise their own claims on God for assurance about the direction of the kingdom, but it is also important for followers to prepare themselves to follow in such a way that their influence could be much more helpful to the leaders in reaching shared goals. Not only do followers who proceed, as Brigham Young said, "with a reckless confidence" fail to develop themselves in their own power and resources, but also they deprive the leaders of the kind of support they deserve and need at times from followers who are themselves developing the skills required. The 58th Section of the Doctrine and Covenants indicates that the Lord expects members of the Church to accomplish much on their own without incessant institutional insistence or prodding. It is neither realistic nor wise to expect leaders to provide all of the answers all of the time, to provide solutions to all of the problems that will arise. This would require leaders to be omniscient; further, it would require of them the kind of sustained energy and time which is simply not humanly possible to give over protracted periods of time.

Love and Marriage

The teachings of Christ suggest that we should begin our search for an eternal companion with greater concern about our ability to give love than about our need to receive it. Of the Savior, John wrote: "We love him, because he first loved us"
Indeed, it may be our own capacity to give love that makes us most lovable. The greater our own personal substance is and the deeper our own mental, emotional, and spiritual reserves are, the greater will be our capacity to nurture and love others, especially our companion.

Leadership

In today's world, it is common to measure one's personal growth by ever-greater positions of responsibility in the workplace or by pay raises that signal increasing personal accomplishment. We often look at visible positions of responsibility as an indication that a person is an important contributor. It is not surprising then that many people struggle to know how best to measure their growth in spiritual matters.
I have heard many Latter-day Saints question their own standing because they have not been called to leadership positions in the Church. But is our progress properly measured by leadership callings?
In fact, leadership does not require a calling. Some people who exert the uplifting and encouraging influence that constitutes true leadership do so with no calling or position
...
Leadership callings are much like training wheels on a bicycle. The training wheels allow a child to learn how to balance and ride with confidence. A leadership calling puts people in a position to learn how to love, be patient, and persuade through pure knowledge and kindness. They may also learn that any attempt to compel behavior is accompanied by withdrawal of the Spirit and decreased effectiveness.
After our release, we will find out if we have grown and learned while in our calling. Have we learned to love and serve others without the calling being the impetus? Have we learned to serve with power as an influence for good simply because of who we have become?

Thursday, September 08, 2011

Porting to PySide/QML: Notification Bar

I keep hearing about how great QML is to learn so I'm a bit baffled as to why I am still having such a hard time with getting more than a toy program written.  I'm trying to save my rant about that once I've gotten an application completed and can help provide more useful feedback.  In the mean time I wanted to cover a set of changes to my python code that will made the QML port a bit easier.  This is regarding code to make it easy both for users to provide good bug reports and for me to figure out what went wrong.

tl;dr

Some sample programs that demonstrate the ideas in this post

Saturday, August 13, 2011

A Swipe UX Idea

Over my desk at work I have a sign that says "On my deathbed I would design a better deathbed".

I've been using the N950 now for several weeks and I can't help thinking about how I would do things differently.  This is not meant to criticize Nokia's work on Swipe.  Swipe works well as a universal gesture.  Even if there are issues with it you and I should recognize this is beta software.  I've heard Nokia has already made one change to swipe since my software build and who knows what else might change before release.

I'm just curious about how else things could be done and the effect they might have on the user experience.  I don't think Nokia should immediately drop everything and switch to my idea.  I first would like to see what they come up with in the finished project.  If I still think mine is better?  Oh well.  People think and act differently, especially programmers, and they are probably targeting others.

Swipe UX

I'd recommend these demos for a quick introduction into swipe.  The main swipes will bring you back to the last home screen you used.  When wanting to swipe to a specific screen you swipe back to the home screen you were on, pause to see which it was, and then swipe over.  You can go about it faster by remembering what screen you were on.  I usually think I know where I was but I tend to be wrong leading me to swipe a few more times.

My variant on Swipe UX

My idea centers on a spatial model that spans home screens, the lock screen, and applications.  This could roughly be translated to virtual desktops with rules controlling which desktop different windows get launched on based on the desktop's role.

Launch an app, no matter from what screen?  As it is opening the device also slides home screens over to the task switcher.  Now with the app up a swipe down reveals the task switcher below.  If instead you swipe up the app closes.  Also you can swipe to the right to move to the launcher or left to move to the events feed.
Idea: Swipe up or down from the lock screen to unlock and reveal the feed
The device goes to sleep?  The lock screen is above the events feed.  A swipe up or down reveals the feed below.  Instead a swipe right moves to the task switcher and left for the launcher.

Idea: Swipe left on the lock screen to unlock and move to the launcher
Open up a folder of icons? The subfolder opens up above the launcher.  A swipe up or down to reveals the main launcher below.    This would provide a simple UI for subfolders to be built into the launcher..  Again instead a swipe right moves to the events feed, and left for the task switcher.

Idea: Swipe Right on the lock screen to unlock and move to task switcher
Applications, home screens, and the lock screen would operate on a more consistent set of simpler rules using a spatial model for the home screens rather than most-recently-used.  From where you are you would always know how to get to where you want to be with one swipe without a pause to think of which screen you are on and what direction you need to go to get to where you want or having to keep an accurate mental copy of the device state.

*Note: The images are mockups only and were hacked together from screenshots I found through Google.

Python Packaging for Harmattan

Right now I am taking a break from learning QML.  Instead I've been adding support for Harmattan to my existing QWidget projects.  It might seem pretty pointless because of how aweful QWidget can be with the default theme.  I will at least have the apps available if I need them in a bind.  Also taking working apps and repackaging them rather than new untested apps provides the benefit of controlling the number of variables to debug when things go wrong.

I will be focusing on packaging for OBS seeing as a QWidget-based application isn't worth pushing through OVI.

Packaging

I had to switch my applications packaging over from my py2deb fork to the distutils-based sdist_maemo.  A big reason is sdist_maemo already has Harmattan support.  I also figured it was a good idea to switch to distutils as it is more "proper" python packaging and because it is pluggable for various target packaging systems.  That last part will allow me to continue to support Maemo 4.1/5 and in the future support regular MeeGo.

So first I've moved all of my files to a proper distutils based layout
  • ./setup.py
  • ./LauncherName
  • ./package-name/*.py
  • ./data/package-name.desktop
  • ./data/package-name.png
I try to reuse code and packaging infrastructure between my projects so this means I need an easy way to diff between them, so I added a symlink from "./package-name/" to "./src".

I then wrote my setup.py file with an sdist_maemo command configured for each of my target deb-based distributions.  A nice thing to know is that for Maemo 5 the python module will be optified for you.

An annoying thing is each platform has different packaging requirements.  Some examples include:
  • Different ".desktop" file locations
  • Different ways of launching the app from within a desktop file.
  • Everything seems different with the app launcher icon
  • Different icon sizes for the Maemo-Icon-26 field
  • Different .deb sections
  • Different dependency names
  • Aegis file support (not needed for current apps so skipped over)
Already the differences between Maemo 4.1 and Maemo 5 were annoying from a packaging perspective.  This makes the problem even bigger.  One approach I've always rejected was maintaining separate packaging scripts for each distribution requiring me to keep duplicate information like the version number.  The approach I used with py2deb was passing a parameter in to my script to change what was passed to py2deb.  That doesn't seem to jive with distutils.  So I threw in a touch of code-gen using a nifty tool called cog.
To minimize my need for using code-gen my setup.py file creates multiple instances of sdist_maemo, one for each platform.

The app icon caused me some problems.  I had assumed it would operate like previous versions of Maemo and desktop Linux, that if you just said "ejpi" or "gonvert" it would look for the appropriate icon size in "/usr/share/icons/hicolor".  I'm glad I found that document explaining otherwise.  As an alternative some of the apps in the OVI Store just hard code an absolute path. When you do make a mistake on this, Harmattan seems to have two different default icons.  The red square came up for me when "ejpi" didn't map to an icon.  The green curved icon came up when I had an absolute path that pointed at nothing.

My makefile creates the needed icons, code-gens my desktop files, code-gens my setup.py files, and then runs "setup.*.py sdist_*".

Odds and Ends

I do not believe PyQt is available for Harmattan, so I had to finish adding support for PySide in my applications.  I've made it easy to use both bindings by centralizing all knowledge of the differences between the two.

I've tried to make the switch a couple of times already but each time I came across new bugs that the old bugs prevented me from seeing.  Luckily the PySide people are quick at resolving these issues and by 1.0.5 my applications ran smoothly.

I went ahead and made the simple switch to XDG and Harmattan-style icons though I'm not yet seeking OVI compliance.  I decided to redo the icons.  They weren't all that great, no where near the icon guidelines, and I wanted SVGs so I could use the Harmattan Icon Generator.  Not being an expert at graphics tools, the icon generator definitely saved me a good amount of work.  The main drawback is that basing the icons background gradient on the base icon's content seems to produce results without enough contrast.  I ended up using the "mean" setting to force gray backgrounds.

Distributing

Now that we have all that wrapped up, time to upload onto the OBS.  The Getting Started Guide has been updated and now is pretty good.  I setup a harmattan-specific subproject due to my code-gen specializing the source-packages per distribution.  Once everything was uploaded to my project, I logged in as root, added my sources, and away I went.

So for the fruit of my work:
Well I guess this means I need to get back to learning QML.

Resources

Desktop File:
XDG
Icon
Package
OBS

Tuesday, July 19, 2011

N950 Arrival and My Development Plans

A couple of weeks ago I was notified by Quim Gil that I was selected for the MeeGo Community Developer Device Program for a Nokia N950 devkit.  Prior to this I had been quiet in Maemo-land for a little bit while I worked on an experimental rewrite of one of my applications that uses PyGame.  Seeing as PyGame isn't on the N950 I hurried up in getting it to a state I could put aside and moved on to learning QML.

The excitement increased as I saw the box personalized with my name regardless of that personalization just being a piece of tape
MeeGo Development

My development plans have changed (and frustration increased) over time as the MeeGo development story has gotten refined.  This is due to both changes in the UI toolkit availability and rules for distribution of applications.

Originally when things shifted to Qt I chose QWidget because it was ready now, includes widgets, and was recommended by Nokia (you know, the people who own Qt) for the types of apps I write (which recommendation was removed on June 22, 2011).  At MeeGo Conference I found out that some (most? all?) MeeGo instances are not including QWdget themes (which without a theme its basically dead).  QWidget in Qt5 will be optional and will probably not be included on those same MeeGo instances that currently don't ship a theme.  So there goes that work.

I am still a bit frustrated with QML in that there is not even a subset of common QML Components between platforms though some disagree on it being a problem.  I've just seen really terrible QML applications which mostly stem from everyone reinventing the same bugs when writing widgets from scratch.  I also find it a wonderful experience having the widgets available for the desktop such that I can write apps in a desktop environment that are targeted for small screens without the need for any pesky IDEs and emulation.  When it comes to testing, I am much more efficient testing and debugging natively on the desktop and just need to spot check how it translates to my devices.

I do not look forward to packaging for generic MeeGo.  I found out at MeeGo conference that dependency management isn't guaranteed to be included and one has to include in their package any dependencies outside of core MeeGo.  This is fine for compiled applications, you just pull in static libs.  This is not as simple for Python developers where part of the beauty is your program isn't compiled and any compiled extensions are distributed and maintained separately.  I have contemplated some tools to simplify this (based on cx-freeze and Hatchet) but that is a good amount of work and focused away from what makes all of this fun.

At MeeGo conference I raised my concern for packaging Python applications during the apps.meego.com lunch time BoF.  The impression I got then (no clue if things have changed) is that they will focus on MeeGo compliant apps at first and might later support others.  Even with that concession this is a stark contrast to the original vision that helped bring me on board from Maemo about (what was then called) Surrounds which would serve both as an app repo and as a place for third-party dependencies.  If I chose to not bundle all of my libraries then I also am not available for any of the other distribution channels (and any contests they might be running).  I don't program for the reward of the contests but it isn't fun feeling excluded.

The beauty of developing for Maemo was it had very low friction in the development story thanks to Python that I was able to spend more time focusing on what was fun: designing software for end-users to enjoy.  I feel that this is being lost in MeeGo.

MeeGo and Nokia

The picture can be better when focusing on a individual vendors.  Vendors may keep things a bit more lax with their distribution channels.  The problem is then you are customizing per vendor which requires device availability for testing and a lot more work.  That vendor has to be worth it.

Nokia is worth it (even without the DDP).  Nokia actually shipped a great device previously (N900 running Maemo5) and is committed to shipping the N9.  That is a lot more than other vendors can say.  On top of that Nokia offers a great experience with the software and hardware.  So as a user, Nokia is worth it.  What about as a developer?  Nokia has Qt Quick Components to provide reusable QML widgets.  They also will support dependencies and have Python/PySide available in their store.

The Way Forward

For my initial ports I will continue to focus on what keeps this fun, writing apps for end-users despite any downsides of being vendor specific.  After that I will bite the bullet of making my applications MeeGo compliant to make them available for a wider audience.
The default date.  It's good to see somebody at Nokia has a sense of humor

I have work to do on all of my applications but I will be focus on the ones that still use GTK first, especially since they are fairly simple.   I am using QuickNote as my playground for learning QML.  Expect further posts regarding progress updates and lessons learned regarding QML and MeeGo 1.2 Haramattan.

Google CR-48

Today I was asked my opinion on my CR-48 ChromeOS netbook to help with a purchasing decision for a Chromebook.  I thought I'd share my thoughts of having used it for the last 6 months.

I have a plethora of devices including most of the Maemo family (just missing the n800), some netbooks I got free through various (legal) means, and my desktop.

Whenever I am out and am needing something bigger than a handheld, I rarely choose something other than my CR-48.  This is because most of what I use are the various Google web apps and I can limp along on other use cases that don't fit in as well.  As an example, my CR-48 leaves the house once a week for my church meetings to assist me in my current responsibilities which is facilitating administrative matters so our congregational leaders get to focus more on assisting people.  An example of when I might chose another device is when I travel to various Maemo/MeeGo events where I'd want something that is a bit more prepared for python development.

The other main use of my CR-48 is what I'll refer to as opportunistic internet usage.  What I am referring to is the reduction in friction when having the thoughts "Oh, I'd like to look up ..." or "I should record ... so I don't forget" enough that you will act upon that thought more often.  This is when I am sitting about the apartment (or out and about) and my phone isn't quite enough to satisfy my need.  This is something harder to quantify when doing comparisons so it is usually not even thought of.  A tablet could also serve this purpose well except they are pricier and don't have a physical keyboard.

With any netbook you have to be honest with yourself about the reduced functionality due to their design, it is just more so the case for the CR-48 as you only have access to a web browser.  This can have some benefits though.  I remember an observation made to me back in the days of PalmOS.  My father preferred PalmOS because it wasn't imitating the desktop.  Why is that good?  When the imitation is too close you are more likely to get frustrated at the gaps when you come across them, sort of an uncanny valley of features.

So what devices should someone have?  It depends on your use case.  I've generally been a person who has preferred a cheap portable with the work horse being their desktop.  This has the benefit of being less paranoid about the portable device and making it easier to replace it when needed combined with the cost savings of a desktops (especially when you go 6 years without replacing them).  It is hard to say what I would get myself when left to my own devices (pun intended) since so many of my devices have been free.

ps If you are reading this and dream of robbing me, look further at the specs, release dates, and niche role of the various devices I listed.  It won't be worth it.

Friday, July 01, 2011

Google+

I still don't have too many people on Google+ but I thought I'd record my thoughts

Circles

I love them.  Some people are a bit confused about them and consider it a privacy risk that people can add you without your permission.  FB has the same problem but doesn't do a good job of telling you.  In FB if you send a friend request and it is never accepted/rejected then your feed will display any public updates from that person.  Google makes this explicit and emphasizes the benefit of it by having a "following" circle by default.  I think it is a much better and simpler model than "friending" products and people or "liking" their Page.

I'm still playing with what I want in circles.  Too granular of circles means you have a lot more to manage for each post.  Right now I am looking at "family", "friends", "acquaintances", "local", and "professional"


For cleaning up my circles over time, I'd appreciate a mass-edit mode where everyone is a row in a table and the columns are the circles they are in.  Bonus points for Google also showing who has not added me back and who I've not added back.

Posting

I like that when commenting on posts you can see what the visibility is of that thread.

Sometimes privacy on my posts isn't a big deal, like talking about programming for MeeGo.  It'd be nice if you could use your circles not just to restrict communication but say "these people will actually care but allow it to be discoverable for people I'm not connected to yet".

Another variant of that global-sharing-with-focused-audience use case is my use case for Twitter.  I originally joined twitter so I could track MeeGo Conference hashtag and know what else was going on around me while in attendance.  A Similar use case that a friend pointed out is tracking live news for things like the Texas legislative session.  I don't think I've seen a G+ equivalent system to hash tags but it will be hard for it to compete with Twitter without it.


Notifications

This is one of the killer features, being able to check on my notifications within GMail.

Feedback

It is nice that it is so easy to find how to provide feedback to Google on Google+.  It is also a really slick tool.  I've already sent them several items for improvement.  I hope they roll this out to their other services.

Integration with other Google products

Currently there is some integration with Buzz and Picasa Web though I am unsure of what Buzz's role is now and am thinking of disabling it.

I am looking forward to this being improved.  Good Google Calendar integration is a must for being a FB replacement.  Blogger shouldn't be too hard to also tie in.  I'd like them to solve the GMail / Google Reader integration issue but not too sure how they'll pull that off.

Contacts integration is actually where users will probably see the greatest troubles.  This is due to trying to bolt together different services that don't always have their data coordinated.  Users have unmerged GMail contacts, contacts creating G+ accounts with different email addresses than what are in my contact book, and the various tags I have from people.  It'll be a mess even with Google's help to try to match up all of these representations of people.

Back to Picasa Web.  I figured I should go back and update my tagging of people in my pictures.  Sadly I can't find the really helpful mass-tag tool that lets you look through all the faces it found and tag them.

Google Takeout

One of the reasons I am loyal to Google products (besides reducing the number of accounts I need) is the ability to leave and this is no different.

Final Thoughts

As I said, Google will need to improve their service integration and slowly ramp up their algorithms taking care of things for me.

Reaching critical mass will be a challenge.  Some might compare this with the migration from MySpace but this is even harder seeing as there are even more users with more history in the service to leave behind.  Maybe that is a good thing, to have a fresh start, but there are some connections that might not transition over that I would miss.

A question for me: where do I post things?  Facebook, Twitter, or G+?

Monday, June 06, 2011

Extrapolating

I give at the office, blood that is.  The organization that does it recently gave me access to my vitals through their website.  I finally took a look and a coworker made a startling realization.

I wonder if our cafeteria at work will start serving brains by 2012.  I bet Sodexo will charge an arm and a leg for it though.