Integrating with 3rd party APIs you'll often need to implement a webhook for your application to respond to external events. It's useful to take the event data and store it in your Database for future reference.
As Kwoosh is run out of Texas, users in Texas need to pay an 8.25% sales tax. To my surprise Stripe's dashboard doesn't seem to offer an answer to a simple question: How much did I collect that was taxable and how much do I need to remit to the state for last quarter's sales.
Armed with our event log data and Python we can quickly get that the numbers we're looking for.
Our data looks something like this. Naturally a real event would have a lot more data, but for our purposes today this should suffice.
This data is sent with eachinvoice.payment_successfulevent and it's saved in aa JSONField in our database. Using the KeyTransform we can extract values from our JSONField and annotate them to our QuerySet. Even better, as of Django 1.11 we can nest our KeyTransform so we can extract values that are multiple levels deep.
Our plan of attack is to annotate the value, sum them together, and return them with the period. Unfortunately we have to sum them in Python until bug#29139is fixed. We're not summing millions of rows so it's still quick enough.
And just like that we can aggregate values from our JSONFields. If you want to sum other fields you can simplyadd another line like this, but replace "tax" with the field you want to sum.
To make it a bit more useful, I built a second function that uses this function to give me quarterly sums.
We can simply iterate over this function and generate a simple report that shows us a quarterly breakdown of our sales and taxes collected.
They say a picture is worth a thousand words. Then a video must be worth at least 30,000 words per second.
To help show how teams can use Kwoosh to manage their software projects, we’ve started to make Screencasts showing off the various features.
My first screencast shows how a Mac (or any other Desktop app developer/team) can use Kwoosh to manage their project. In the video we setup the scaffolding and start adding tasks for a batch image resizing application.
Kwoosh’s take on project management is slightly different than most current systems. Our core thesis is that software project management shouldn’t much differ from project management used for building an airplane or a rocket. I don’t think Waterfall is making a comeback, but rather, using aWork Breakdown Structure(WBS) is the best way to get an accurate feel for the size of the project and the work required.
Using a WBS, you take a given project and divide it into smaller and smaller pieces of work until it no longer makes sense. When it no longer makes sense to divide a task, you should be able to confidently estimate how long it will take to complete. If you are estimating that a single task will take longer than an hour or two, it’s likely that you haven’t broken your task down into indiviual actions. It’s this lack of breaking down tasks sufficiently that leads to incorrect estimates, as you have not fully thought through the problem.
Since apps are naturally divided by screen and sub-screens, Kwoosh uses screens as the primary way to organize your project. To illustrate this concept we’ve built a number of pages that show how your team can use Kwoosh to manage different kinds of software projects.
Each team I’ve worked on has had the same struggle: figuring out what’s being worked ontoday.
Each team tried to solve it in a different way. Some had morning meetings. Others did stand ups. And others left ticket numbers in a chat room.
All of these solutions worked. Some took more time out of the day than others, but the team general knew what was planned for the day.
Where all of these fell short was that you had to piece each report into the larger picture of the day’s activity yourself. This is quite difficult unless you are already knee deep in the project. And the inevitable curve ball goes completely unnoticed by your team.
The feedback loop is also quite slow. You don’t find out what was completed until the next day at the earliest.
I’m working on a new solution for this problem called Today. Today lets you and your team setup their day in Kwoosh by clicking “Add to Today” to the tasks you plan to work on that day.
The planned work for the day and the day’s activity are collected together into a single page. You can see the day for your entire team, a single app, screen or user. You can quickly answer what work is John working on today? Or is anyone working on Login screen today?
Today is the easiest way to plan your day and let your team know what you’re working on - all within Kwoosh.
I recently had the opportunity to speak atDjango Congressin Tokyo on May 19th about lessons learned while building Kwoosh.
Preparing the talk was a good opportunity to reflect on how much Kwoosh has changed in this past year. Sharing some of what we learned was a lot of fun. Real code from old and new Kwoosh are inmy slides.
One of the major lessons I learned and spoke about was avoiding Class Based Views (CBV). Class Based Views are a great idea: remove most of your repeitive code into a common class and mixin only the bits you need. However, each time I’ve tried to rely on only CBV I’ve always ended up with code that was difficult to follow.
Our solution was to completely ditch CBVs and write Kwoosh using regular function views. In my talk I shared our approach to make the migration while allowing us to reuse code. I was surprised after the talk when a number of people came and asked see how we did it.
The basic idea is that we have a regular view and use decorators to wrap our functions with shared functionality. Inside our view we can define a number of functions to handle each method that we wish to support. A view looks something like this:
How is this different from just a CBV with a method for “get” or “post”? First, it’s easy to see exactly how the code executes. You’re not left jumping between 3 different files, documentation, or even diving into the Django source to understand the flow. Second, we can handle multiple get responses from a single endpoint e.g. an admin user gets this response while a regular user gets another. Lastly, we have the freedom to name our functions however we’d like.
The supporting decorators are quite simple and remove a lot of the grunt work from creating and maintaining new views in Kwoosh.
Creating multiple decorators like has allowed us to get the best of both worlds: code reuse and a simple execution path.
This week we deployed our first stage of switching from a Just In Case (JIC) to a Just In Time (JIT) data strategy forKwoosh.
Currently we provide all the data for a given page on each request. This means that the user might be sent 10 data records or 200. This method is fine when you have small data sets, but as things grow and you return more data the page loads begin to slow down, and most of the data you return isn’t needed by the user.
A traditional way to solve this problem is to add pagination. This allows you to only return a small subset of your data at once and keep things fast and near infinitely scalable. The issue with this is that users have to click to go back and forth between different results, and you can run into issues if new data is added between result pages.
Modern web apps look to solve these problems by auto loading the data when the user scrolls or the screen has empty space to show more content. This means the user doesn’t have to click between pages, and, if done correctly, feels like all the data was originally loaded but without the long wait time.
We have started our journey down this path by creating a data source component withinVue, that takes over the job of obtaining the data the page needs and asking for more when it’s needed.
Normally, when a part of a discussion about your project is deleted, it’s gone forever. Depending on the particular discussion, it may not be a problem. Rather than delete data, Kwoosh allows you to remove data. The subtle difference in meanings between “delete” and “remove” makes all the difference and this difference heavily informed our implementation.
Some things we considered:
What happens if a user clicks a link on an old email into Kwoosh and the item has been removed? If the item was deleted, there would be no data to display and we return 404 Not Found. The consequence is that the email has lost vital context and information. Knowing that data could just be gone forever could make people cautious about referencing data in Kwoosh. If you’re cautious about referencing it, then you’ll get it into the system to begin with.
After an Item has been removed, what happens to it’s child items? So if you remove a task with 3 sub-tasks, do we also remove those sub tasks as well?
If a user can view removed data, they will want to be able to restore it some of the time. How do we prevent data from appearing in the system when removed, and upon restore, appear in exact state that it was before being removed originally. i.e. removed sub-tasks are still removed and previously uncompleted tasks appear as open in the system again.
The way we handled this was splitting visibility into two different flags: status and visibility. Status denotes the status of the item as either ACTIVE, or INACTIVE. While visibility controls visibility as either VISIBLE, HIDDEN, or MASKED.
To keep us from accidently showing removed or hidden data we set our default query to filter only ACTIVE items. To queryallitems, we must explicitly query all_objects. It looks something like this:
In our example above of a task with 3-sub tasks all items would default to ACTIVE, VISIBILE.
When we remove the parent task, it becomes INACTIVE, HIDDEN. Uncompleted children are then updated to be ACTIVE, HIDDEN while completed tasks are not modified and remain as ACTIVE, MASKED.
A couple of methods allows us to remove and restore entire trees of data in a very simple and speedy way.
I’ve built and sold software for the Mac and iOS. Those products all had simple billing systems. On the Mac, I just plugged in a framework eSellerate and added a couple of hooks in my software to integrate. eSellerate handled all of the billing, taxes and so forth. This let me focus 100% on my product, and then tack the part that allowed customers to pay me. For the service they charged around 10 or 12%.
On iOS (and later on the Mac) it was further simplified by Apple handling everything via the AppStore. This was a huge benefit because no work is required by the developer. They can focus 100% on the app, at least as far as payments are concerned, and it costs 30% of the app price. However, they lose the ability to communicate with their customers, unless they build out forms in their app to collect that information.
Both of these cases are all one-time sale purchases. Send an email on purchase and you’re finished. Using something like eSellerate or the AppStore and it’s all done for you.
With a SaaS, you need to handle all of that yourself. You need to handle payments, and invoices and everything inbetween.
And that’s when I realized we hadn’t addressed that part of the application yet. We had built in a Sign Up screen to create accounts, but not the 90% required to make it usable by actual customers. It’s easy to forget all of this extra work exists until you start thinking through:
a. What are the next actions you want a customer to perform (i.e. Sign Up) b. If you were a customer who just performed an action (Signed up) what sort of communications might you expect and when might you expect them c. What kinds of documents might you need to procure to pay for the app e.g. an invoice to send to your boss to authorize the credit card payment
Some of the “hidden”work, work outside of our main app, we needed to complete was as follows:
Create an account and start a trial with our payment provider when customer account created
Charge sales tax for users in Texas
Which means we needed to knowwhereour customer lives, so building out a form, database table, and workflow to allows users to display and edit their address
Synced with our payment provider and update sales tax accordingly
As Kwoosh licensed per-user, sync their subscription when a user is added or removed
Display a list of invoices
Create a view to display a single invoice
Pull in event information e.g. when was this invoice created, when was it paid, and display it.
Make sure the breadcrumbs make sense for the context
Welcome Email drafting, screenshot production, and coding
While it didn’t seem like a lot at first glance the amount of work on a non-core feature to make it right is quite large. While I’m happy with the backend, our invoice display needs a bit more work. As this is our workshop, our place for show and tell, I present you with our Work in Progress Invoice screen.
Read these 5 books. Take this online course. Subscribe to those newsletters. Watch these videos. Sign Up for this webinar.
Everywhere you look people are trying to throw knowledge at you as the silver bullet to solve all your problems. They tell you that you can’t succeed without their five step process for only three easy payments of $29.95. They tell you that the reason you didn’t succeeded before was that you didn’t know their methods; you need to build an audience, pick a niche, hire a designer, make a viral video, code it in ruby, create landing pages, create a hashtag. All of which you can learn from them.
The thing is: you don’t need more knowledge. You already know enough to start today.
Before starting we think we must be able to answer every issue that could possible occur, lest someone on the Internet think we’re stupid.
We watch inspirational videos. We drive to that coffee shop that plays just the right music. We research tools to to handle customer support before we have any customers. Anything that tricks us into feeling progress without actually making any progress.
You don’t need to read another book, you don’t need to take a course, you don’t need to watch more videos…you just need to start and work hard.
The thing standing between you and your goal isn’t knowledge, it’s work
When we work on Kwoosh we break everything down into tasks. We then break those tasks into multiple sub-tasks and those into sub-tasks etc. This leaves us with bite-sized chunks of work that are never too big to overwhelm us. We are removing all obstacles between our minds and getting the task done…we invite you to join us too.
This week I’ve been working on updating our page headers to be able to show more data. We like how clean they currently look, and don’t want that to change too much. We also knew that not all users or situations will require extra data. So we had to come up with a balance between allowingsomeusers to quickly see extra data, and not interfering with those who didn’t need it.
For this we came up with a hidden area under the header that would slide down when you wanted to see more, and slide back up when you didn’t.
We had previously only shown app details on the app overview screen, so we then moved these details into the new header section, allowing the information to be viewed from any screen within it. Making it much easier to find and access when you need it.
And that’s it! We will continue to add more data and features to the headers as we go along, but for now it works well and can be replicated across all sections ofKwoosh.
Applying the final layer of polish on a product is fun, but it’s always more work than anticipated. The bit I applied tonight is a small detail to tell you who was last active on a discussion.
When displaying a discussion in a list we show the title and a list of the participants’ icons. The easiest solution for telling was last active is to add the name of the last person who commented lsat.
That didn’t seem like the right solution. Showing their name adds an extra piece of information for each discussion, pulls your eye away form the titles, and quickly makes the screen feel cluttered.
I adopted instead to highlight the user who commented last. As the order if the icons never change, you can tell who started the discussion glancing at the left most icon.
Let’s take a quick look at how tasks work withinKwoosh.
Tasks allow you to track a single chunk of work that needs to be done on your project. They can be detailed or brief. Tasks can be assigned to users and prioritized with drag and drop. Like screens, you can highlight tasks different colors to assign extra meaning.
Tasks are infinitely nestable. This is great for keeping track of any sub-tasks that need delegation, and allows you to break down and plan out larger tasks into clear next steps.
Nesting also allows us to show you the full context of your work. Sound complex? It’s not.
What you’re seeing above is Jane drilling down into her website project. She’s able to quickly understand the context, relationships, and structure. She can see which tasks remain in each section, and has broken down and assigned sub-tasks to members of her team.
Ugh, not this scenario again. Yep. It’s 16:59.59 Friday evening; your fellow co-workers are heading for the door but you aren’t. Why? Because you are stuck at your desk desperately searching for an old bug report: your boss has sent an urgent bug report that looks vaguely familiar.
What was it titled again? Was it tagged “critical” or “urgent” for checkout?
You’ve tried todo lists.
You’ve tried kanban boards.
You’ve tried bug trackers.
Each of the above systems struggles to track exactly what needs to be done on any particular screen at any given moment.
Once you have chased down what needs to be done, you find yourself jumping between email messages, chat logs and wiki pages, like some made forensic scientist, to piece together the context surrounding the task.
So much wasted time and energy.
Kwooshlets you add tasks directly to the related/relevant screen. That bug you fixed last week on the checkout? It’s on the Checkout screen. No guessing. No searching. No unrelated tasks distracting you from solving the actual issue at hand. But most importantly, no panic
Issues with the reports screen are attached to your reports Screen. Features for the dashboard on your dashboard Screen. Everything is right where it logically should be, not hidden away a single unmanagable list.
One of the many ways to define a components template within Vue.js is by using the render function.
Let’s take a look at how to use it.
createElement function basics
Here is a basic outline of the arguments the createElement function accepts and how to use them.
This would output the following:
Let’s now look at how to render a very basic template.
Now let’s make it a bit more complex and add in multiple child nodes.
We can then pass data to the component via a prop and use that within the template.
When you’re starting a new web app, how do you get a handle on the scope of the work? How many times have you been so focused on the details of big features that you forgot to account for the time required to design and build the login and password reset screens?
Let’s say you’re building a new blog-based microsite for a client. Being that it’s a blog, you figure you’ll need roughly the 4 different screens below to complete the project.
But as you think the job through more, and start adding placeholders for the more custom pages, a single list becomes unwieldy. It doesn’t actually keep you organized. And yet, this is how most project management tools assume we work.
They are centered around a single bucket of tasks. And from said bucket you’re expected to imagine the relationship between the screens. Not just once, but every time there’s any change to the project or your team.
If you were building a house, this would be like having a giant pile of wood, screws and wire as your blueprint. And each time you move some priority around you’re dragging wood and wire in the pile – not very efficient or obvious.
A better way to organize our house would be to have separate piles. All of materials and plans for each room grouped in their own piles. A pile for the master bedroom, a pile for the second bedroom, a pile for the kitchen and so forth.
This does a good job of helping us at least organize and communicate everyone automatically which materials belong to which rooms. We can also easily verify that each room has enough materials and adjust our plans quicker and easier.
Better yet would be if we could have levels to help us group our work knowledge by floor. The bedroom piles are in the upper level, signifying they’re on the second floor, and the kitchen materials are on the bottom level, because they’re on the ground floor.
Immediately looking at this sime layout we should be asking ourselves more details. How are they going to get to the second story? Our current plans leave room for two solutions: a secret staircase or a ladder tacked on outside the house.
Likewise by organizing our projects the way we expect to use them we are able to identify seemingly minor details that have a huge impact on our projects. What’s more, the structure can automatically conveys the intended hierarchy of our app. There’s no need to guess.
Why struggle to organize your project as a single list of tasks when it’s not? Kwoosh builds structure into your project management process and is designed for software projects.Try Kwoosh today.
Our post schedule got derailed over the past few weeks. It’s that time of year where side projects get thrown to the sidelines because of the holidays. Instead of sitting down to write for an hour; you’re seeing family, putting up Christmas decorations and ice skating at the local mall.
These are all contributing factors, but putting aside a slightly bruised coccyx, we got derailed for a lack of mental bandwidth.
This post is my attempt to get back on schedule.
Each day you’re given a certain amount of creative bandwidth. Once the allotment is depleted, you can either stop or push on, stealing from tomorrow’s supply.
Grinding on is sometimes the right choice, but it’s unsustainable. You can handle a day or two, but if you push too hard for too long you’ll burnout entirely. Recovery from the burnout then requires an undetermined amount of time to recharge and pay back your debt.
Recently, I’ve had a lot on my mind, draining my creativity before my first cup of coffee. What was on my mind? Packing and preparing for a move to Japan, preparing for a presentation at the Houston Tech meetup, Thanksgiving plans, and enjoying some last-minute travel while I’m in Texas.
I knew that with all of this happening, choosing to grind on would quickly lead to burnout. Most of the pressing issues would pass in a few weeks and then my mind would be clear to focus. After work I didn’t want to write, I just wanted to veg on the couch and watch YouTube.
After my talk I started sleeping better. Less weighing on my mind. Now with my house packed and on a boat to Japan my mental bandwidth bottleneck finally cleared. I felt like I could write again.
Sometimes we must push ourselves to in order to keep our schedules. Other times we must recognize when pushing does more harm than good and force ourselves to stop for the day or week.
When the bottleneck clears we’ll be able to eagerly pick back up where we left off. Refreshed and ready to go.
If a tree falls in the forest and nobody is there, does it make a sound? If a tweet is sent and nobody can see the number of likes was it still worthwhile?
When people launch new products, they often focus on vanity metrics: How many eyeballs do we have? How many followers do we have? What’s our Klout score? They desire to quantify every interaction.
Part of this is the human desire to seek rewards. The hit of dopamine given for our effort. The bigger the metrics the bigger the hit, and greater the urge to do it again. We soon however get into a cycle of complacency. 10 ‘likes’ is no longer enough, then 20, then 50.Your post was worthless if you didn’t get 100 ‘likes’.
I’m guilty of this myself. When I publish a new article I spend the next few hours desperately refreshing the stats page.1 like…5 likes…10 likes…I had 20 likes by this point on my last post…What a waste of my time…
I’m no longer happy with just the process of creating. I now focus my happiness on a number that the product designers probably added with little thought. I serve at the pleasure of the metrics.
Did anyone ever bother to stop and think how displaying these numbers would affect the way that people use a service? What would a world look like without vanity metrics? Would I still get the satisfaction if I didn’t know how many people liked it?
Imagine for a moment if Twitter didn’t plaster its UI with counts. No number of followers. No number of retweets. No like count. Nothing.
If you didn’t know 15k other people retweeted something in your feed — how would this affect your behavior? Do the number of retweets signify influence and your perception of the tweet’s trustworthiness? Would you still retweet it?
Is it more difficult to tweet and get started with Twitter when you see that you have 0 followers, 0 retweets, and 0 likes every time you tweet?
Would you post a different picture if you weren’t trying to get the most likes? Would you tell a different story? Would you still check-in at the airport?
What if you could see your numbers, but you couldn’t see anyone else’s numbers? You could see you have 100 followers but not that @tomhanks has almost 13 million. Would that change how you use the platform? Suddenly, from the outside at least, all voices are equal. The game of getting more followers and these other vanity metrics would stop.
Would you treat a DM from somebody with 5 followers the same as somebody with 50k?
While it’s tempting to add numbers and counts to quantify everything in our products, doing so can have adverse and unintended consequences. Instead of allowing for creative freedom, people censor themselves to better play the game.
A single number can change your whole outlook.
So before you add that count to your design, ask yourself: does it provide information which is directly actionable for my users? If the answer yes, add it in, but if not, leave it out and see, maybe people will use your product totally differently.
Many large software organizations split their teams into functional teams: designers doing design, system admins doing operations, developers writing code, and product deciding how the product works.
The idea is simple: let people do what they’re best at and you’ll have an efficient team doing what’s best and in the end you’ll have a coherent product. Product thinks of a new feature, takes it to design to design, who then works with the developers to get it made a part of the product.
While this may result inaproduct, it also results is a team with large siloed blind spots. Product only sees the tip of the iceberg of that new feature and design makes the feature fit as well as it can, saving it’s energy to fight for another day. After everything’s been decided the work is then passed off the development to make it work.
As a developer it’s easy to acquiesce and just build it thinking, “Hey, I’m doing just what they told me. And besides, it gives me an excuse to try out this new library”. We then try to pass the blame of a poor product off to the product team - afterall, it was their idea.
However managing software is a developer’s job. They’re the only ones with a full sense of the “how” the entire thing works, so it’s up to them to make sure the product doesn’t become compromised. You wouldn’t let a home buyer insist on changes that would compromise integrity of the building and software is no different.
Below are three questions you can ask yourself and your team to help figure out if you should include that new feature in your product.
Is this a core competency?
Are you asking a bear to ride a unicycle? Sure, it may technically be possible for a bear to ride a unicycle, but it doesn’t make sense. Are you building photoshop into your CRM so people can crop their profile photos? If feature play doesn’t play to a core strength of your product, leave it out. The feature will be half-baked at best. If you must include the feature outside your product’s core competency, try offloading the core to a third-party tool whose core competincy is that feature and integrate OR reduce the scope as much as possible.
Where does this feature belong?
Where does this feature belong and how does this fit into the user’s workflow? It’s all too easy to just create a menu for “orphan features”, features that don’t really fit anywhere in the app, but are being shipped anyways.
Ask yourself what users will be doing and what kind of urgency they’ll typically be feeling when using a given feature. If you can’t come up with a better location than the orphan menu, it may be best to leave the feature out until you can.
Who’s going to use the feature and how often will they use it?
Who’s going to use this feature and how often are they going to use it? Is it a report they’re going to run daily? Or is it something they’ll run once when first start using your product and then rarely after that? If it’s something people are going to access often, make it easy to find.
Recently my main task has been creating a subsystem that will allow us to integrateKwooshwith third party services. We useSlackquite a bit, so it seemed like a good first choice.
The plan is give you the option to enable Slack for your account. Then on each App, you setup where you want the Slack notifications to go. Right now I think Kwoosh will only send them with task related events: new task, completed task, and so forth.
It’s still a work in progress, but I couldn’t wait to share.
As I polish it up I’ll continue to share more videos and screenshots of Slack integration.
I was recently invited to join a new online forum system by a friend. I clicked the link in an email I was sent and entered a password (they already knew my email address as my friend had given them it).
Once signed up, I clicked around 3-4 pages, joined a few topics of interest and then left. I spent about 60 seconds on the site in total, before seeing it wasn’t really something that I would be interested in.
Four days later and I’ve received 12 emails from them.
4 daily digests for the different topics I had expressed interest in and 8 individual emails for new posts and replies to older posts.
There is no reason to EVER send a new user 12 emails in such a short period of time by default. I ended up unsubscribing from all the emails (they were alldifferentand so required 3-4 different unsubscribe links), and now they will never get the chance to entice me back to their website as they have abused my trust.
What they should have done is start off with a single digest of activity every few days and then as I started to use the site more…ask me if I wanted to get individual emails about every action that occurred on their site.
This way I would have gotten used to seeing them appear in my inbox. Maybe clicked on a few of them over a couple of weeks, and started to build up a routine about visiting them.
It is very rare that a user would ever need to know about EVERY action on their account, and once you overload a user with information they zone it out and you can never get them back. The boy who cried wolf is a good tail to remember…if everything is treated as a “stop in your tracks and read this” event…then users won’t read your really important alerts when they matter.