Introducing TKit

trifl

It’s still in progress, but I’m already using the basic functionality in a library I will release under ‘trifl’ called TKit

The goal is to become a toolkit that is, on its own, pretty damn useful.

For now its a bunch of extensions, but I would like to focus on custom libraries soon, for animations, data persistence, navigation, notificaitons, etc.

One such tool that I’m proud of is TKTimer, which lets you do really interesting things using timers with or without durations. :D  It’s very useful, let me know what you think!

Swift!

swift

Apple has announced Swift, which is going to replace Objective-C, and therefore make the really awesome libraries I’ve been working on (JPKit) kinda old.

But that’s ok! Because I will learn Swift by porting the whole library to the new language (thankfully it’s still really small!)

Check back soon for those updates. When will I have time this week to do it….? Hmm.

Updated JPToggle!

I just had the urge to update JPToggle, and it was a lot of fun!

What’s new?
- You can now add multiple contexts at once!
- NSNotification Support (you can now get notified when toggles change, to make real time changes to those toggles)

And there are lots of unit tests ensuring that this stuff actually works. :)

I hope to build out a way to support A/B testing soon (or A/B/C/D….. testing, because why not?)

Enjoy!

JPToggle

I created a basic feature toggle library for iOS called JPToggle, which can be found on Github

It’s really easy to use, and since this blog post will get outdated, I will refer you to the README file.

Basically, I wanted a way to add/remove context (like DEBUG, DEMO, ADHOC, RELEASE, etc..) and have the toggles work accordingly.

The library comes packaged with tests, and I hope to only improve on it from here on out.

Coming soon: Notifications.  Objects can register as observers for toggle changes.  Maybe I’ll even see about integrating with ReactiveCocoa.  We’ll see.

Anyway, enjoy, and tell me what you think.  I would like to use a similar concept for a cloud based feature toggle service, but that’s still a thought in progress…

Weekend Startup anyone?

I have this idea to turn Sixpy into a weekend startup.  I have a full time job and a social life, so I can only dedicate so many hours a week to Sixpy.

Here are the commitments I expect from the team:

1. Equal founders
Everyone in on this from the start will get an equal cut of the equity over 2 years. This is supposed to be a very fast moving startup, so the first vesting period is at 6 months, and then you will vest more every 2 months after that.  It’s a lot of hard work in a little bit of time, but if Sixpy isn’t launched in 6 months, we’re doing something really wrong. (Version 1 is NOT that big)
We can discuss pitching in some money to have a ‘fund’, or we can just start working (though, some money to get accounts like JIRA and Github–both cheap for small teams– or to get us together comfortable would be useful–but we can figure that out based on what everyone is comfortable with)

2. 16 hour work week
Everyone needs to commit to 16 hours of work a week.  If we can do that, I know we can launch version 1 in under 6 months, with plenty of extra features just waiting to be developed.

3. 10 hour estimates
Ideally, we’d each complete at least 1 feature/task a week, and our estimates will be based on a 10 hour work week (to make up for our meetings and for downtime). Finishing early is a good thing because we can start on new tasks.  Just remember, we’re committing to 16 hours per week, and we’re trying to get this thing launched in under 6 months, all while filling whatever roles need to be filled.  It’s a team effort!

4. Daily emails
We should all spend a couple of minutes each day responding to the emails we receive within the team.  This makes sure nobody is blocked and work isn’t piling up on anybody!  Perhaps a required daily update email would help keep our minds on Sixpy for those 16 hours per week.

5. Weekly group meeting
It will be hard to get everyone to schedule all of their work time to be together, but something we can do is commit to just 1 meeting every week at a certain time that’s just 1 hour long (see why we only estimate for 10 hours?)

6. Presentations via wiki
Due to the small amount of together-time, if you have something to present, put it on the wiki and send out an email!  Everyone is responsible for watching/reading the presentation (via #4), and taking care of their daily emails. :) (this should take little time if it’s done regularly!)

I imagine this team to be 3 or 4 people large.

So, the members? Let’s call them: JP, B, C, and D

Roles (in order of highest priority to lowest)
CEO
– JP
Developer #1 - JP
Dev management - JP
Designer – (Slot most likely filled) B
Marketing - (Slot most likely filled) B
Developer #2 – ?? C or D
Systems Admin – ?? JP, C or D
Build Automation – ?? JP, C or D
JIRA/Wiki organizer - ?? JP, B, C and/or D

Of course we will help each other and fill whatever roles that need filling.

My general rule of thumb is: the person who is the most fit and the most available for a role should take on that role.  There’s no reason person C should do marketing if person B is more fit and more available for it.  Person C should fill another role if he/she is low on work.

Sixpy already has a good amount of work done!  The foundation is built (server side and client side), and I’m quite proud of it. :)

The first week or two will be a little different depending on your role.

The designer will be working with me to better understand the app, then designing the few first pages that will need to be developed.  In that time, I will also be setting up dev and test environments as well as getting automated builds to work.  Before any dev work continues, everyone will be a beta tester of the current app.  I estimate 10 hours for all of this. (So, that first week)

If I have a dev#2, that person can push on some of the server work needing done.  I think the existing code provides an easy template on what to do. It’s a REST api, so it’s mostly (MOSTLY) a matter of writing SQL queries and keeping the code as neat as the existing code. :)

Then I continue building the iOS app!  The designs will be ready so it will just be a matter of implementation at that point.

Code reviews will be required!  This is really easy to do with a GitHub account, and I do not want to sacrifice quality of code.  It will only bite us in the long run.

I think with the right team, we can launch in 5 months. I want to see this in the App Store, or at least in a VC’s hand, in that time (if not sooner.)

Stay tuned for part 2: manifesto.

Six-word app? What six-word app?

Do not fear, it’s still happening!

 

sixpy

 

 

 

 

 

 

What I have done so far:

  • Amazon Server is set up
  • REST API started (server)
  • Login via Facebook (server and client)
  • Create six-word posts (server only)
  • View newest six-word posts (server and client)

I want to post about the development process more, but more importantly, I want to start showing off the app, but to do so, I want it in beta 1.  What will be beta 1? Well, it will be a working iPhone app that lets you:

  • Log in via Facebook
  • View newest posts
  • View newest posts by word *
  • Post
  • Follow other users
  • View basic profile

* Every six-word post, you’re able to dive into by touching any of the six words in that post.  This will navigate you to a page displaying all of the recent posts with that word in it.

I have a long ways to go, but I took off this whole week for some R&R, to get some errands done, and to work on Sixpy a little :)  So, hopefully sooner than later, I’ll have something to share.

For now, check out <a href=”http://www.sixpy.com”>the teaser page.</a>
Until next time!
- JP

What is JP working on?

Other than raising pokemon in Pokemon Y, I’m building a 6 word poem app. :)

Inspired by my lovely girlfriend, and similar to http://www.sixwordmemoirs.com it will be an iOS app that is basically twitter, but limits you to writing in just 6 words.

Hopefully I’ll have SOMETHING to show you soon. :)

- JP