Jul. 21st, 2017 12:14 pm
tensegrity: (Default)
I'm in the final stages of getting an iOS app ready to submit to the Appstore. It's another silly, simple game. The basics are in place, I just need about 4-5 additional pieces of art and to fine tune the play matrix. But I haven't added any sound effects yet. I seriously dislike noisy apps to the point where I normally keep all sound effects turned off on all my mobile devices. And the only thing worse than a noisy app is one with badly done noises. Still games–even simple ones–should be immersive, even for brief episodic use, and adding sound helps that. 

I am not feeling enthusiastic about delaying this app in order to do sound design and source effects for it. I can add them in an update, but you only get one first impression, right? Except this is a free app. It's designed to be simple. The graphics are hand-drawn. The words are minimal. Ugh. Ok, I was planning submitting in early August. That gives me another week or so to finish things up. If I get inspired to design some sounds, then it will happen. If not, it's going ahead without them. Either way, there will be an update to the app before the end of the year–probably shortly after iOS 11 is released.

The next decision is whether or not I want to go ahead and write an Android version of the same app. I should. I just can't muster much in the way of enthusiasm for it. We'll see.
tensegrity: (Default)
One of the cool things at WWDC this year was machine learning. Is it a hot dog? Is it a rose? I saw a number of demonstrations and sat through several presentations about how iOS will be able to import a variety of models. Very cool and exciting. But you need to have a trained model to import and creating one is in an entirely different scope. And honestly, every time I've dipped into the programming literature, the math quickly went beyond my comfort level in terms of being able to understand what the heck was going on.

But then I found a pointer to the TensorFlow project, and decided to give it another try. Reading through their tutorials, I started to have a suspicion that I might actually understand what was going on. And then I tracked down this article,, and suddenly it all started making sense. Machine learning is applied statistics, and in its simplest form, it's not even very complex statistics. Which also explained why the trained models they were adding to iOS projects were so very small; the models are just equations. Now, they can be fairly complex equations, but they're just equations.

When they call it machine learning, it's easy enough to assume that the model continues learning as you use it, giving it more data. No, by the time you begin using the model, all the learning is done, at least with the systems I've looked at. The learning part happens when you let the code tweak the equation to better fit what you want to see as a result, and that's where the dangerous part is. There are a number of decisions the model binder has to make and they all influence the outcome of the model, and that's not even touching the quality of the data set or whether the assumed correlation is real enough to be useful. And even if you don't make a wrong step in making and training and tuning the model, it's still dependent upon past data. If the nature of the correlation changes, it will invalidate the model.

All of which is a fancy way of saying that if someone comes to you with a fancy machine learning model, don't treat it like a magical black box, because it isn't. Also, brush up on your statistics if r-squared is still greek to you. Really, it's not that bad, and it can come in handy when reviewing scientific studies or listening to economists.

WWDC 2017

Jun. 11th, 2017 12:40 pm
tensegrity: (Default)
I finally won the lottery and was able to attend WWDC this year in San Jose.

Good grief, were there really only 5,000 attendees? It felt like twice that many. It was a lot of people and a lot of time spent in crowds moving from one place to another. On the other hand, Apple has definitely had time to figure out how to manage this type and size of event. There was a small army of staff functioning as cheerful and intelligent sign posts and bollards to back up the crowd control ropes. The timing of the presentations also left plenty of time to exit the enormous presentation rooms, get to the other end of the convention center, and line up to enter another enormous room for another presentation even with crowds so big that no one could move quickly.

There was a lot of thought put into the various break areas, and I do mean various. You could sit outside at a table or on a towel on the green (sadly, astroturf) parts of the plaza. You could camp out on cushions in a stepped seating area integrate into the main stairs. There was a bright seating area. There was a darkened hall that also had monitors showing the current presentations with closed captioning. There was music, just loud enough to cover the crowd noise, and places to sit out at the edges of the halls where there was no music. There were options for soft comfy seats, tables for groups, and tables for just working. And just about anywhere you went, you could find an electrical outlet.

The food options always included vegetarian and healthy choices, and the quality was decent. Once I figured out the timing and placement of snack services, I didn't have to worry about going hungry or being thirsty. The biggest issue with eating was finding a place to sit, and that generally meant having another chance to chat with someone from somewhere else in the world, whether from Germany or China or South Africa or Puerto Rico. I even met someone else from Kansas City.

Yes, there were women attending. Not enough of them, but they were there. I even had to stand in line for the bathroom a few times during the week. I even ran into a few black females developers. Honestly, there seemed to be fewer black developers than female developers attending, in spite of tickets being handed out via lottery. Still, it was a wonderfully diverse group of nerds.

It's great to see Apple continuing to push the implementation and use of accessibility features. It helps to put a human face on the people it really helps. (As much as I try to push for accessibility in the apps I work on and have for years now, I was still caught off guard by what a difference Siri makes in the lives of some people. I confess that when it came out, I thought of it as a silly convenience, not an accessibility feature. I was wrong, Thank you, Todd Stabelfeldt.) I still think it's potentially even more effective to show decision makers that properly implementing accessibility helps everyone, not just people you think of as disabled. Apple could do even more by requiring that accessibility features be implemented where appropriate in order to put apps into the app store. One step at a time.

So, I had a good time and learned a lot. Even more I have an enormous list of things I want to learn more about now that I'm back home. So many exciting ideas was a huge take-away from the experience. Still, one of the downsides to this even for me is that really using all this lovely technology tends to require getting locked into the Apple ecosystem. In my work world, that is almost never an option. Apple has chosen to chase profits over market share, but my clients have other constraints on their business choices and that affects what I can do. So I have to look at all the shiny toys with an eye toward the real world. If I sell a particular technology, can I also support it on Android? Life would be so much easier (and yet still complex and challenging) if I were only supporting one platform.

Would I go to another WWDC? Oh yes. Will I get to go? I don't know. At this point I'd be tempted to pay my own way if my employer wasn't willing. The problem is that just having money isn't enough because of the whole lottery thing. And if my team grows over the next year (and I'm surely hoping it does), we won't be able to risk having the entire team go to WWDC, and having finally been, I'd have to step back and let someone else go. Maybe I can try to go to Google IO nest year instead.
tensegrity: (Default)
Yesterday I got to conduct my first technical interview and there are two more to do today. It was interesting to be on the other side of the table and I'm finding that I have strong opinions about technical interviews.

Yesterday's happened with very little notice. I only had about an hour to prep for it and we didn't have a standard set of interview questions ready. (Our team used to have a list, but it hadn't been updated in several years and has disappeared in a reorg at some point.) And just to make it interesting, we really would like to get a mobile unicorn, someone with strong skills in both iOS and Android, even though we don't expect to find one. Oh, and preferably they can work in a specific cross platform tool and have some experience with hybrid apps that incorporate web content.

Of the three interviews this week, one candidate has iOS experience, one comes from an Android background, and one is mostly a .Net developer. We only get to hire one person for now, so how do you structure a technical interview in this case? I've had to come up with four sets of questions; iOS development, Android development, mobile development, and a general set of personality/working style questions. With ten to fifteen questions in each set, I should be able to pick and choose appropriate questions for any given candidate. I'm most of the way there but I'll be doing some refining of the list over the next week.

Opinion time. I hate trick questions. I hate them. I also think that deep in the weeds technical questions are bullshit for most interviews. I also dislike questions that ask people to regurgitate bullet point lists or interface details that can be easily looked up; they tend to be lazy questions that don't tell you much about a candidate. I like questions that tell me whether a candidate understands the jargon of a field and has an understanding of the shape of the problems to be solved. I like questions that give a chance for the candidate to express themselves because communication skills are critical. If you've worked in more than one language and more than one toolset over the course of a few years, then you've probably mastered the skill of learning new languages and toolsets. If you don't know the ones we're working with, you'll learn them. But if you can't communicate effectively, that's a deal breaker.

Ideally, the questions should never be phrased in such a way that they encourage a yes or no answer. But how do you get useful information about someone's skill at estimating the time required for a project? How can you evaluate debugging skills in a phone interview? I'm working on it. In the meantime, I am also leaning one heck of a lot about writing resumes.
tensegrity: (Default)
Dear creator of audio book apps, (Axis 360, I'm looking at you), we need to talk about how people listen to audio books. Perhaps, in an ideal world, everyone gets to sit down to listen to an audio book straight through. Or maybe they get to listen to a chapter at a time. But when I'm listening to an audio book using my phone, I am in a supremely interruptible context. The app I'm using should expect that I'm going to have to stop listening at any time and that I might not come back to listen again for quite awhile. I might be using any number of other apps in the meantime, or I might have to reboot my phone.

If my audio book app cannot keep track of where I was when I was last listening, even though I'm still on the same device, I'm going to get quite irate. I am exactly the sort of freak who will happily listen to a book in five or ten minute chunks with hours between listening sessions. Because your app can't seem to keep track, I either have to remember to set a book mark every time I pause, or else I have to fast forward through to try to find where I was when I last stopped. If you only have five minutes to listen and you spend half of it searching for a place to start... you get irate.

And really, although I can be an odd duck in many ways, I don't believe that my listening habits are all that weird. Yes, this is an app for library provided audio books. Should I really be complaining? Well, yes. I love libraries and I am an enthusiastic user. I could afford to buy all the books I read (and listen to), but I believe our libraries are an important resource and should provide a good experience for everyone.

Ok, that's enough fussing for now.
tensegrity: (Default)
Estimation is one of those scary things in software development. (Well, in lots of places, but this is the context I work in.) You don't want to make your estimate so low that you can't possibly complete the work in the allotted time, but if you make it too (realistically) high, you stand good chance of never getting to do the work at all.

And then there's the problem that lots of people believe that most of the time that goes into delivering a software project is actually spent writing the code. So when the estimate looks scarily high to them, the first thing they want to cut is the time spent on writing the code. It's not at all unusual to get a request to cut the development part of a project by fifty percent, at which point you sit down with the account team and walk through all the work that's included in that estimate, plus the fact the development costs (at least in my area) generally run 10-20% of the total project. Once you convince them that zeroing out the development budget doesn't get them to their goal, a more productive conversation can begin. (But don't let them talk to you about budgeted project hours without also discussing delivery dates, otherwise they're likely to slip a fast one in on you.)

Last week we had to deliver an estimate with very little lead time. It was just a minor feature update, but it was for a complex set of platforms with multiple options and looming cliffs of technical debt. Monday morning we get word that our estimate is too high. We need to cut it by 80-90% before we can even consider presenting it to the client. Our jaws dropped because that is insane. If they were serious about the numbers, then the clients expectations were majorly skewed and we should probably stop wasting our time. I spent all day gnawing fingernails over the expected battle we'd see in a late afternoon meeting.

As it turned out, the dev numbers were fine, although we dropped back to only supporting one platform as a slow roll out strategy. The real savings were whittled away from most of the other teams involved. It still wasn't anywhere close to a 90% cut, but it was large enough, and we helped the account team craft a story to sell the project with a preview of additional work to be done next year. Now it's out of my hands and not my problem until or unless I get a request for a variation on the initial estimate.

If you happen to be in the weeds with estimating software development, especially hybrid mobile development, I would strongly suggest never providing just a single number. It can still be high level, but you need to put together a line-item breakdown of the work you're estimating, preferably with a high/low range. Then, most importantly, you need to document all the assumptions and known factors that could impact the validity of the estimate. This includes areas of uncertainty which have caused you to provide a higher than usual estimate for a particular item. If you do enough similar projects, you can do a lot of copying line items and numbers from one estimate to the next, but it's alway worth your time.

And if they absolutely insist on a high level, ball park number and you can't negotiate enough time to put it in writing with a ten thousand foot line-item breakdown (yes, I try to do breakdowns at that level too), then add a generous fudge factor to your number before sharing it. And inform the recipient that there's a fudge factor inflating the number to account for uncertainties. (Personally, I wouldn't volunteer the magnitude of that fudge factor, partly because it's often based on prior experience with the team that's asking.) If the number makes them flinch, just remind them that it will decrease as uncertainties are resolved.

Happy estimating!
tensegrity: (Default)
1. What I'm Reading

The Rise of Io by Wesley Chu
I still haven't finished reading his Tao books, but they're on my list. In the meantime, this one is keeping my interest. And now I kind of really want to read a review of the use of the idea of two minds in one brain in SFF and all it's variations. 

This Census-Taker by China Miéville
I probably shouldn't be reading this one right before bed; it's weirding me out enough that it's proving slow going. 

2. What I'm Making

Back to socks. Plain jane vanilla, toe up socks. I've decided to rebuild my sock collection, and by sticking with a plain knitting pattern I am free to pick crazy sock yarn to knit with. I've also limited myself to knitting no more than 12 pairs of socks this year, mostly because knitting at this gauge is hard on my hands. Plus, too much knitting makes it too easy for me to be sedentary. I finished pair number two this weekend, and also a mini version to add to my collection of tiny socks. 

I also made a Dutch Baby pancake for the first time in ages, but I was out of AP flour so had to use bread flour. Drenched in fresh lemon juice and sprinkled with sugar it was quite tasty, but more like a muscular pancake than a popover. 

I still have two small paintings in progress but didn't touch either one of them this weekend.

I still have an app in the works, but spent the weekend getting development tools installed and updated instead of writing code. 

3. What's Making Me Happy

Friday night we had a former club mate take time out of a brief trip back to the area to come fence with us again, five years after moving away to the east coast. It made for an excellent practice and it as great fun to see him again. It was also touching to find out just how much of a difference our little fencing family made in his life, newly arrived from Mexico. 

I still have the windows open, and when a thunderstorm rolls in on a Saturday evening, I can lay in bed in the dark with my kindle listening to the rain and thunder. 

I'm looking forward to having an out-of-town visitor this week. It'll be a short visit, but it makes me ridiculously happy.

4. What I'm Doing

Aside from having a visitor, this weekend I'm helping a friend celebrate her graduation, going to a Science Fiction and Fantasy art show, and participating in Tabletop Game day. Which is sort of a ridiculous social schedule for me, but it should be fun. Other than that, I'll be working on my current coding project.

5. What I'm Looking Forward To

Next week I have a ticket to Pirates of Penzance, and an invitation to soak in a hot tub to raise money for Planned Parenthood. I'm also looking forward to making progress on this coding project.

tensegrity: (Default)
Ah, the dreaded state selection list. It sounds like such an easy and natural solution. You need to pick a state, so present a list of states to select from. Done!

So first you ask, is this just for domestic U.S. use, and they say yes and breathe a sigh of relief, because this makes things easier. Fifty states plus, yes, the District of Columbia. All set.

Then you ask whether the software might ever be used in Puerto Rico, and the smiles go away. Don't ask about the Virgin Islands or Guam or other territories because they'll never believe that their application will be used in those places. But Puerto Rico? That makes them stop and think.
tensegrity: (Default)
I'm still looking for an acceptable implementation of a dynamically categorized list view in Android. The good news is that I have a much better handle now on how Android wants to deal with the darned things, but I'm frustrated by the lack of built-in support for such a useful feature. Or maybe my google-fu is not yet properly attuned to finding Android things. All the stuff I'm finding with section headers is in the context of static list content and I hate to go the route of using a third party implementation for something that feels this basic.

Maybe my design sense is just too tuned to iOS? Are Android users more accustomed to scrolling through long lists? Is it more usual to provide explicit filtering of the list instead of doing grouping? I suspect I'm going to end up finding a way to use structured filtering to meet my needs. I keep reminding myself that breaking out of my usual patterns is a good thing. It's also a good reminder that I need to review more good Android apps to see how other folks are solving interface problems in that context. Which means I probably ought to budget for the purchase of an unlocked Android phone to play with, even if it is more work than play.
tensegrity: (Default)
Yeah. It's been a day or something. I don't want to talk about that. I nearly played hooky this morning; it's so nice out! As it turned out, it was a good morning to be in the office because I got dragged into two different kick off meetings for one project. (And it sounds as if there was another one earlier that my team wasn't involved in?) And, of course, it's an Android tablet app. (Enterprise distribution, so no, you won't be able to get your hands on it unless you're in the right place at the right time.)

I have such a reflexive dislike of Android dev in the abstract, and it's silly because I haven't minded any of the droid apps I've actually worked on. I have a theory that there are Android people and Apple people, like there are dog people and cat people. Obviously, Android people are the dog people and I am very much a cat person. I understand cats and I understand iOS. Dogs and Android apps are a bit of a mystery. Oh, I can get along fine with individual dogs and Android apps once I get to know them, but give a choice, I'll go for cats and Apples every time. Ah well.

No, I didn't get around to playing with sectioned list views last night. I saw a bit of the news and decided it was a good time to put away all my screens for the evening and settle in with a book instead. Tonight is fencing practice, although we'll be missing a few epeeists due to it being first Friday. (Maybe I can get in some practice in giving drills.) Tomorrow I need to hunt down an appropriate birthday gift for the tweener god daughter, and Sunday is booked with social events. Maybe I can get the list view sections working before I go to fencing.


Apr. 6th, 2017 05:15 pm
tensegrity: (Default)
Small amounts of progress this evening, but it's two steps forward, one step back. I am well and thoroughly tired of the Android debugger. And looking at the code to support sectioned list views... ugh. I think I'm just tired and need to do something completely different. Got date formatting today and handled some sequencing issues. The list views (aside from grouping) have gone fairly painlessly but there is something amiss in my detail view and I need to dig into the details of the debugger a little further to figure out what's going on there.

I've found using the debugger with Android Studio to feel inconsistent. Not sure if it's the debugger or a side effect of the way I'm using/abusing Firebase. Sometimes, in order to debug, I have to start the app and then attach the debugger to the running process instead of starting the debug directly.

Ok, I found a different description of how to accomplish the sectioned list view and it looks well written. I've bookmarked it to look at later, maybe after I've had some dinner.

Ug, I just remembered that I really need to upgrade my personal machine to Sierra. Maybe I can make that happen tonight. Tune in later for the further adventures.

Droid Me

Apr. 6th, 2017 09:35 am
tensegrity: (Default)
Having been an Apple girl for quite a few years now, I am now facing the prospect of getting comfy with Android, both as a user and as a developer. It's been a bit rocky, but I'm slowly making progress.

Objective-C was so comfy for me, and Swift has surprised me by being even better. Java? I was never a fan. It's taken being forced to do some maintenance on an Android project, then being tasked with learning Xamarin (eek!) to get me over the don't-wanna's. Weirdly, having to work with Xamarin in C# has made it easier for me to approach Android development.

Right now I'm in the process of putting together an app to get into the app store as part of maintaining my developer portfolio. And this time I'm doing both an iOS and an Android version of the same app using Firebase as a back end service. (I got curious about it after attending a Google Dev event.) And no, I'm not using Xamarin for this project, although I might eventually do a Xamarin version just for the experience. I've been puttering about with it (mostly adjusting to Firebase) for about a month now in my spare time. The iOS version is at bare butt minimum viable. The droid version is about half way there after a major refactoring last night. (I predict at least two more rounds of refactoring before achieving Droid MVP.)

And you can tell I'm a developer because I've only had the sketchiest of thoughts as to the visual presentation.
tensegrity: (Default)
Social media is such a strange thing to manage. My LJ will be going away soon, so I figured I might as well get settled in here. And no, I am not moving all my LJ content over here, but I will be posting here on a semi-regular basis.
tensegrity: (Default)
Baking even mediocre bread makes the house smell good and improves my mood, and this batch was a step up from mediocre. And eaten fresh, almost any bread is good. Eating too much though, is not good, so I make small batches.

Read more... )


I still have the second loaf to munch on tomorrow.


Aug. 20th, 2010 01:55 pm
tensegrity: (Default)
While doing some cleaning this week (and what a week it's been, I cannot recommend cleaning highly enough as means of keeping the spirits up after being laid off) I came across a copy of Spevack's "The Harvard Concordance to Shakespeare" that had been languishing in a back room. It is a rather large book. The spine is three inches thick and the cover is roughly fifteen by twelve inches. It's 1600 pages of everything in Shakespeare, more or less. As a reference work, it is a thing of beauty. If I had had this book in my teen years, I would have been delighted. (Oh, look. Five references to weasels.)

This week, I was ready to donate it to the local library book sale, until I opened the front cover and found that it had been a gift to my stepson from one of his high school teachers. Said child has since run away to Argentina to get married and won't be wanting it any time soon. But still, I can't quite just get rid of it. It still has a dust jacket and is in good condition. I can't tell if it's a first edition or from the second printing. Either one puts it at north of hundred dollars in value, and a first edition could fetch considerably more. And if he'd known that, he probably would have sold it rather than leave it behind. For now, it has found a shelf to live on until its owner retrieves it or a new owner is found.

But for all it's loveliness, I can't help thinking that this is exactly the sort of book that ought to be printed electronically. It practically begs for it. A properly formatted edition would be a great improvement over the paper in almost every way.
tensegrity: (Default)
From my desk

Pelikan Souverain 400 using Iroshizuku Syo-ryoku ink.


Apr. 28th, 2010 10:20 am
tensegrity: (Default)
Breakfast April 28, 2010

Sheaffer/Levenger Seas pen using Iroshizuku Yu-yake ink.


Apr. 27th, 2010 08:17 pm
tensegrity: (Default)
Dinner April 27, 2010

Namiki Vanishing Point using J. Herbin Cafe des Iles ink.

Expand Cut Tags

No cut tags


tensegrity: (Default)


RSS Atom

Most Popular Tags

Style Credit

Page generated Oct. 21st, 2017 05:18 pm
Powered by Dreamwidth Studios
July 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 2017