First defined by Andy Hunt and and David Thomas (1) in 1999, Tracer Bullet development describes an approach of getting the main functionality of a program implemented as fast as possible to a) collect feedback and b) see if this thing works after all.
In recent years this approach gained more popularity as it was taken up by the team around GROWS Method (2). The idea behind this approach is simple: “A working prototype is worth more than a thousand concepts.” It has become a common practice to create paper-prototypes or wireframes for visual interfaces to break down complex logic into more easy to understand visuals. The same applies to tracer bullet development. The critical piece in a piece of innovation is implemented without too much regards to compatibility of existing systems, legacy support or anything the like. As soon as this rough “code sketch” solves the core-problem, it can be tested against existing system, users, etc.
Especially in early-stage projects where complex technology is involved, it is definitely worth to think about not just visual mockups but also “technology mockups” in form of tracer bullet development to explore technical feasibility early in the project.
Build. Learn. Iterate.
Sources:
1) The Pragmatic Programmer: From Journeyman to Master (1999)
2) The GROWS Method (2014)
[coding] : passing parameters to carrierwave uploads
TL:DR; If you want to use jCrop, carrierwave and fog to crop images BEFORE they are uploaded to the cloud, do the following:
1) Add instance variables to your model:
2) permit those params in the controller (be careful about the order, the file needs to be the LAST thing you pass):
3) add the cropping method to your uploader and add process :crop to the version you want to have cropped:
That’s it :) Interested about the long story?
Here we go: This one has bothered me for two full days now and since there were no suitable stackoverflow answers and carrierwave tutorials didn’t work I thought I’ll post this here. In fact, it’s a pretty trivial problem:
We’re currently rewriting parts of Smaply. We use jCrop in frontend to give users the ability to choose which part of their uploaded picture they want to make the profile image of personas. It looks something like this:
So, when the request comes in from the frontend, it’s basically a multipart-form with four additional values (crop_x, crop_y, crop_w and crop_h) which define the area to be cropped.
Carrierwave offers the possibility to create versions and give them sizes. What it doesn’t suggest however, is a standard way to pass my request params over to those instance methods.
There are several suggested solutions:
http://stackoverflow.com/questions/21706445/rails-jcrop-rmagick-bootstrap-no-method-error suggests that you should recreate the version after creating the image which really sounds like unnecessary overhead to me and brings problems if you use fog.
http://railscasts.com/episodes/182-cropping-images-revised same suggestion as above. I don’t want to upload, then crop and upload again.
https://medium.com/philosophie-is-thinking/carrierwave-process-parameters-or-makeit800-com-casualty-of-the-zeitgeist-12e80a80d754 suggests to use instance variables in the uploader. TL:DR; IT DOESN’T WORK since a new instance is created as soon as you pass the file param.
http://stackoverflow.com/questions/10631060/how-can-i-pass-arbitrary-user-defined-values-into-a-carrierwave-image-processor works perfectly fine in Rails 3.
At first I fell in love with suggestion number 3, since it felt better to have those instance variables in the Uploader class itself. However this approach just doesn’t work because Carrierwave triggers the upload as soon as you pass in the file param and therefore creates a new instance of the Uploader class where those attributes are obviously nil.
I converted to “puts driven development” mode and added some statements and a byebug marker in order to be able to debug a little better and understand the Carrierwave internals. Here is the log output that catched my attention (I pixelated some swearing of mine):
So, option Number 3 didn’t work either. Back to the basic idea of just adding those instance variables to the model itself as suggested in the last Stackoverflow Link above. But somehow it still didn’t work until I scrolled further down:
So, several hours of bug hunt just to crop an image according to user input. That’s it. Since I didn’t find anything comprehensive on the topic, I decided to wrap up my findings and hope that it turns out to be useful for some of you out there.
"Diejenigen, die zu klug sind, um sich in der Politik zu engagieren, werden dadurch bestraft werden, dass sie von Leuten regiert werden, die dümmer sind als sie selbst."
Last week I attended this years edition of Servdes in Lancaster, UK together with my smaply co-founder Marc Stickdorn. I learned a lot in intensive 3 days fully packed with workshops, sessions and not to forget: enjoying our time in England. Awesome, open and inspiring people :)
so here are my personal #lessonslearned. They are more or less abstracted to a meta-level. Of course I also learned about specific tools but these will be part of a different post as I want to try them in our startup and see how they work:
There is a vivid discussion going on about defining service design and the terminology used in this field. Some define it as an industry, some say it's an old hat in a new cover, others say it's a toolset. Some say "you cannot be a service designer but rather 'do' service design". My personal take on this one is that service design provides a toolkit that connects various different disciplines like design, (change) management, engineering, ux, ... and gives them a common language. Depending on your project you dig deeper in one or another discipline and apply the tools that are useful. This, for me is not a definition but rather an hypothesis that I try to disprove and question.
* At the beginning of a creative process pen and paper beat digital tools. Always.
* Open innovation and co-creation need open and unstructured spaces AND facilitators. You cannot create "shitty first drafts (1)" in a clinical lab environment.
* You cannot "embed" design in organizations. It's already there.
* The name "design" can be both a cure and a disease at the same time. Depending on your discipline, it open's up a whole new world of possibilities or narrows your world down to "interface design".
* There are complicated problems (putting a man on the moon, replicable) and complex problems (evolution, learning, not replicable). We try to solve complex problems with linear logic.
* For change to happen, you always need a sense of urgency.
* Borg (2) interaction = service interaction = humans inside!
* Define personas that want to harm you and exploit your system.
* Your product, also if it's digital got a face and a certain tone. Give your software a persona and define how it interacts with users.
* maybe the most important asset of a person doing service design is to be a good facilitator. Create a safe space for people to be willing to explore ideas, prototype, fail and try again.
* "With great chicken comes great responsibility" -> Thank you adamstjohn for my very personal rubber chicken :)
This list is certainly not complete and many things may seem like "common sense". It seems to me that one fundamental idea of service design is about bringing together various disciplines to solve complex (see above) problems.
Comments and criticism welcome, either to [email protected] or on Twitter: mrblackmountain
(1) shitty first drafts: This idea tries to embrace "incompleteness" for first drafts. They don't need to be super detailed and crafted with every edge case in mind. In fact, a first draft SHOULD be shitty. It doesn't need to be polished. Actually, the less polished it is, the more likely you are to throw it away if it doesn't work.
(2) borg in this case defines any kind of human computer interaction (HCI), regardless of the interface (console, ticket machine, laptop, tablet, *insertdevicehere)
I happened to be on a project which was concerned with generating .ics files to export events to iCal, Mobile Calendars, Outlook, you name it. This particular task I had to do in php but actually it's more about the format of the final ics files in order to work. It took me some time to get to a proper solution but finally this blog post solved all my problems:
Nobody NEEDS to learn how to code unless they really want to become a coder or enjoy learning it. If you just want to understand how IT and software development works, learn the concepts behind it. I drive my car daily. Do I need to learn how to build it in order to be able to drive it safely and within legal restrictions? NO!
Okay, here's the long story:
In recent time I often read extensive blog-posts about why people need to learn how to code and that in some years you will be lost if you are not able to code (interestingly all of them are coders). I disagree.
Of course it would be nice if everybody would have a basic understanding of computer science. But i don't see the point why coding should be more important than for example to learn first-aid properly and not just 8 hours once in your life... (as it is the case in austria) There is more important stuff out there than to learn how to code.
There are so many things one can learn that help yourself and others. Coding certainly is one of them. BUT there is no use in joining a “learn to code in 24 hours” course just to “get a better understanding”. You won’t get it. The digital world just moves too fast that learning how to code helps you get a better understanding of how IT works. It’s like asking people to learn how to build an engine in order to be able to drive a car and be aware of the risks
CODING IS NOT EVERYTHING.
In fact it’s only a tiny little part in the whole digital world. You are better off if you learn the concepts it is based on: Networks, Security, how an http request works, legal issues, … THAT IS THE STUFF THAT BRINGS YOU A BETTER UNDERSTANDING. Of course coding is “in” right now, and yes you can do amazing stuff if you are able to code, but knowing how to assign a variable, or what an array is, or how to mess around with basic JavaScript doesn’t get you any further. Learning how to code and especially dealing with bugs is a pain. If you don’t WANT TO LEARN how to code from the deepest bottom of your heart, it’s wasted time.
A real-world example: We could implement a course were high-school-kids are teached how to code. Now does that give them any understanding of online privacy? Or on what they should share and where? Or of what online piracy is? Or of what they should take care for when they buy stuff online? What a digital footprint is? So what? Teach them how to deal with it. Not how to code.
Another one: My non-technical co-founders have not the slightest clue of how servers work, what load balancers are, what data-integrity, I/O models or hindenbugs are. And I didn’t even mention the word “code” yet. But we get along perfectly fine. They trust me and I trust them. Every one of us has his or her field of expertise. We try to understand each other as far as we can but same as I have to trust the designer sometimes that what he says is true, he has to trust me that choosing this over that framework is the right choice. I just don’t see were a course in “web fundamentals” on codecademy that he could attend improves the quality of our decisions (of course it's fine if he WANTS to do it and enjoys it). Even if you are a programmer you often have to trust other programmers in their decisions. Just take backend vs. frontend as an example.
It is a question of respect and trust. Try to get good as good as possible at one thing. That is enough.
