TulipeMoutarde.be

Dependency injection in Axum handlers. A quick tour

2023-08-24T04:00:00+02:00

Dependency injection is an elaborate word to say that we want to introduce flexibility in software systems. Instead of having one big ball of functions, we slice it into components that talk to each other. Sometimes we want to be able to swap a component for another one in certain circumstances. Testing is one of those circumstance: we want to test components in isolation. This is especially true when we have external dependencies (eg., talking to a remote APIs).

Rust is no different than all the other languages when it comes this principle. But Rust being Rust, the user gets to decide how to do it. The language provides the building bricks and the user chooses themself the abstractions they want based on the performance hit they are ready to trade off for convenience.

We will start with the static dispatch approach with no flexibility whatsoever and move to more flexible approach.

Context</h2>
The context of our little exploration is an axum</a> app that uses a database of some sort. The database access is provided to all the handlers through the State</a> mechanism provided by Axum. We also have a templating system to generate HTML. We picked handlebars</a> but it could be anything.
We assume that the database access is just one component that is used by the handler. We can imagine that other components are made available through the state (e.g., an AWS service, an external payment API or a redis connection).
All the code is available on github</a>.

Static Dispatch against a struct</h2>

This is the straightforward approach. We define a struct that will hold everything and use it in our state.

#[</span>derive</span>(Clone)]
</span>pub struct </span>AppState {
</span>    </span>pub </span>templates</span>: Handlebars<</span>'static</span>>,
</span>    </span>pub </span>db</span>: MemoryDB,
</span>}
</span>
</span>#[</span>derive</span>(Clone)]
</span>pub struct </span>MemoryDB {
</span>    </span>items</span>: Arc<HashMap<Uuid, String>>,
</span>}
</span>
</span>impl </span>MemoryDB {
</span>    </span>pub fn </span>new</span>() -> </span>Self </span>{ </span>/* .. */ </span>}
</span>    </span>pub</span> async </span>fn </span>all_items</span>(&</span>self</span>) -> Vec<(&Uuid, &String)> { </span>/* .. */ </span>}
</span>    </span>pub</span> async </span>fn </span>get_item</span>(&</span>self</span>, </span>item_id</span>: &Uuid) -> Option<&String> { </span>/* .. */ </span>}
</span>}
</span>
</span>pub fn </span>build_router</span>() -> Router {
</span>    </span>let</span> state = AppState {
</span>        templates: </span>build_templates</span>(),
</span>        db: MemoryDB::new(),
</span>    };
</span>
</span>    Router::new()
</span>        .</span>route</span>("</span>/</span>", </span>get</span>(handlers::index))
</span>        .</span>route</span>("</span>/item/:id</span>", </span>get</span>(handlers::show))
</span>        .</span>with_state</span>(state)
</span>}
</span>
</span>
</span>mod </span>handlers {
</span>    </span>pub</span> async </span>fn </span>index</span>(State(</span>AppState</span> { </span>db</span>, </span>templates</span> }): State<AppState>) -> Html<String> { 
</span>        </span>/* .. */ 
</span>    }
</span>
</span>    </span>pub</span> async </span>fn </span>show</span>(
</span>        Path(</span>id</span>): Path<Uuid>,
</span>        State(</span>AppState</span> { </span>db</span>, </span>templates</span> }): State<AppState>,
</span>    ) -> Html<String> { 
</span>        </span>/* .. */
</span>    } 
</span></code></pre>
AppState</code> always holds a MemoryDB</code> and our handlers are tied to it because
we've declared that the state holds an AppState</code> (State<AppState></code> in the
handler signatures). This is the simplest way to use a shared state on all the
handlers but it is the less flexible as the DB implementation is hardcoded.</p>
Static Dispatch with Generics</h2>
To be able to swap the database component with another it can't be a struct
anymore but a trait. Coding to interfaces, not implementation</em> would say
the purist:</p>
#[</span>async_trait</span>]
</span>pub trait </span>DB: Send + Sync {
</span>    async </span>fn </span>all_items</span>(&</span>self</span>) -> Vec<(&Uuid, &String)>;
</span>    async </span>fn </span>get_item</span>(&</span>self</span>, </span>item_id</span>: &Uuid) -> Option<&String>;
</span>}
</span>
</span>#[</span>derive</span>(Clone)]
</span>pub struct </span>MemoryDB {
</span>    </span>items</span>: Arc<HashMap<Uuid, String>>,
</span>}
</span>
</span>impl </span>MemoryDB {
</span>    </span>pub fn </span>new</span>() -> </span>Self </span>{ </span>/* .. */ </span>}
</span>}
</span>
</span>#[</span>async_trait</span>]
</span>impl </span>DB </span>for </span>MemoryDB {
</span>    async </span>fn </span>all_items</span>(&</span>self</span>) -> Vec<(&Uuid, &String)> { </span>/* .. */ </span>}
</span>    async </span>fn </span>get_item</span>(&</span>self</span>, </span>item_id</span>: &Uuid) -> Option<&String> { </span>/* .. */ </span>}
</span>}
</span></code></pre>
Add a generic with a trait bound to AppState</code> and we're done.</p>

</span>#[</span>derive</span>(Clone)]
</span>pub struct </span>AppState<D: DB> {
</span>    </span>pub </span>templates</span>: Handlebars<</span>'static</span>>,
</span>    </span>pub </span>db</span>: D,
</span>}
</span></code></pre>
And that's where the painful part starts. Generics are viral and propagates
throughout the code if you don't contain them.</p>
Our handlers are not so simple anymore as we have to define the trait bounds for
each of them:</p>
pub</span> async </span>fn </span>index</span><D: DB>(
</span>    State(</span>AppState</span> { </span>db</span>, </span>templates</span> }): State<AppState<D>>,
</span>) -> Html<String> { 
</span>    </span>/* .. */ 
</span>}
</span>
</span>pub</span> async </span>fn </span>show</span><D: DB>(
</span>    Path(</span>id</span>): Path<Uuid>,
</span>    State(</span>AppState</span> { </span>db</span>, </span>templates</span> }): State<AppState<D>>,
</span>) -> Html<String> { 
</span>    </span>/* .. */ 
</span>}
</span></code></pre>
In this example it is quite simple as the only generic parameter is the
database. But the more components we need to swap, the more generics (and their
bounds) we have to add for each and every handler</em>. This situation is
well described in Julio Merino's article</a> about static
dispatch.</p>
Traits to the rescue!</p>
Static Dispatch against a trait</h2>
Once again, traits can help. Instead of having AppState</code> as a concrete
implementation, we can turn it into a trait which will stop the infamous
generics invasion:</p>
pub trait </span>AppState: Clone + Send + Sync + 'static {
</span>    </span>type </span>D: database::</span>DB</span>;
</span>
</span>    </span>fn </span>db</span>(&</span>self</span>) -> &</span>Self::</span>D;
</span>    </span>fn </span>templates</span>(&</span>self</span>) -> &Handlebars<</span>'static</span>>;
</span>}
</span>
</span>#[</span>derive</span>(Clone)]
</span>pub struct </span>RegularAppState {
</span>    </span>pub </span>templates</span>: Handlebars<</span>'static</span>>,
</span>    </span>pub </span>db</span>: MemoryDB,
</span>}
</span>
</span>impl </span>AppState </span>for </span>RegularAppState {
</span>    </span>type </span>D = MemoryDB;
</span>
</span>    </span>fn </span>db</span>(&</span>self</span>) -> &</span>Self::</span>D {
</span>        &</span>self</span>.db
</span>    }
</span>
</span>    </span>fn </span>templates</span>(&</span>self</span>) -> &Handlebars<</span>'static</span>> {
</span>        &</span>self</span>.templates
</span>    }
</span>}
</span></code></pre>
The users of the AppState</code> trait don't have to know the actual type of D</code>,
only types implementing the trait have to provide the actual type. For example,
the RegularState</code> implementation og AppState</code> says that it uses MemoryDB</code>.</p>
We can now build a router without knowing the explicit type of the state:</p>
pub fn </span>build_router</span>() -> Router {
</span>    </span>let</span> state = RegularAppState {
</span>        templates: </span>build_templates</span>(),
</span>        db: MemoryDB::new(),
</span>    };
</span>    </span>build</span>(state)
</span>}
</span>
</span>fn </span>build</span><A: AppState>(</span>state</span>: A) -> Router {
</span>    Router::new()
</span>        .</span>route</span>("</span>/</span>", </span>get</span>(handlers::index::<A>))
</span>        .</span>route</span>("</span>/item/:id</span>", </span>get</span>(handlers::show::<A>))
</span>        .</span>with_state</span>(state)
</span>}
</span></code></pre>
and the handlers are back to a sane definition:</p>
pub</span> async </span>fn </span>index</span><S: AppState>(State(</span>state</span>): State<S>) -> Html<String> { 
</span>    </span>/* .. */ 
</span>}
</span>
</span>pub</span> async </span>fn </span>show</span><S: AppState>(Path(</span>id</span>): Path<Uuid>, State(</span>state</span>): State<S>) -> Html<String> { 
</span>    </span>/* .. */ 
</span>}
</span></code></pre>
A bit of trait dance and no dynamic dispatch. It is quite handy when performance
is important.</p>
There are two drawbacks to this approach though:</p>

For every combination of dependencies, we have to define a new struct that
implements the AppState</code> trait. Again, we only have the DB here but it might
become crowded quite quickly in a real application with different test
scenarios.</li>
As AppState</code> is a trait, there is no way to directly match agains the actual
fields in the handler definition. Components are exposed through methods on
the trait. Some might argue that it is a good thing.</li>
</ol>
Dynamic Dispatch against a trait object</h2>
This approach will be familiar for anyone coming from an object oriented
language. In Rust parlance, the trick is to use a trait object</a>
via the dyn</code> keyword.</p>
This incurs a small performance hit because the application will determine
at runtime</em> the actual implementation to use when a function is called.
But in the context of a web application it does not matter that much (until it
does) as the overhead of all the other things (eg., database query, templating)
is much bigger.</p>
#[</span>derive</span>(Clone)]
</span>pub struct </span>AppState {
</span>    </span>pub </span>templates</span>: Handlebars<</span>'static</span>>,
</span>    </span>pub </span>db</span>: Arc<dyn DB + Send + Sync>,
</span>}
</span>
</span>pub fn </span>build_router</span>() -> Router {
</span>    </span>let</span> state = AppState {
</span>        templates: </span>build_templates</span>(),
</span>        db: Arc::new(MemoryDB::new()),
</span>    };
</span>
</span>    Router::new()
</span>        .</span>route</span>("</span>/</span>", </span>get</span>(handlers::index))
</span>        .</span>route</span>("</span>/item/:id</span>", </span>get</span>(handlers::show))
</span>        .</span>with_state</span>(state)
</span>}
</span></code></pre>
Handlers are back to their initial implementation:</p>

</span>pub</span> async </span>fn </span>index</span>(State(</span>AppState</span> { </span>db</span>, </span>templates</span> }): State<AppState>) -> Html<String> {
</span>    </span>/* .. */
</span>}
</span>
</span>pub</span> async </span>fn </span>show</span>(
</span>        Path(</span>id</span>): Path<Uuid>,
</span>        State(</span>AppState</span> { </span>db</span>, </span>templates</span> }): State<AppState>,
</span>    ) -> Html<String> {
</span>    </span>/* .. */
</span>}
</span></code></pre>
Conclusion</h2>
The full running code is available on github</a>. </p>
As usual, Rust lets you choose the abstraction level that fits the need for the
task at hand. It is sometimes daunting to know which approach is the right one
for a specific use case.</p>
When in doubt, I would go with the simplest solution that provides enough
performance. In this case the dynamic dispatch route is the most flexible while
being more than fast enough for a web application that is driven by SQL calls
and external APIs. </p>
If you are interested in the subject, Julio Merino's blog</a> is worth a
read as he explores this space. Luca Palmieri's blog</a> and book Zero To
Production in Rust</a> are wonderful resources to get started in web
development with rust.</p>

How to botch an interview 2019-12-23T20:06:36+02:00 I've just spectacularly failed a technical interview for a Rust position. The funny thing is that a) it's the first time I apply/interview for a job b) It's the first time I talk about Rust with experienced Rust programmers. Gentle Rust</h2> Lately, I've used Rust as a replacement for Ruby, Python and Swift. I like the confidence it gives me when writing code. Going back to my code a few weeks/months later and not being afraid to modify it makes my life easier. To a lesser extend Typescript (and its awesome integration into VS Code) gives me similar feeling even though the potential to shoot yourself in the foot is still high and the whole Javascript ecosystem feels fragile and klunky. I usually write single thread CLI tools or HTTP servers with a full featured framework. By doing so, I never had to really care about threading and concurrency. As long as I don't block the thread with IO operations I expect the code to be fast enough. Actually, speed has never been a goal. The correctness and the ability to change/refactor code without fear is what really convinced me to use Rust, performance is a byproduct. More Involved Rust</h2> When doing the interview, I was clear that the team was at a much more advanced stage. A lot of questions were about topics that I remember reading and understanding in the Rust book but never encounter in real life. Simple example: the Send</code>/Sync</code> marker traits: I read about them, they are not a advanced concepts, they are super useful when you deal with concurrency but yet, I never had to explicitly mark some of my structs with them. We also briefly mentioned the async</code> ecosystem, how it works and what do the available schedulers offer. This has been a hot topic in the Rust community this year. I've read about futures but have never been close enough to actually have precise answers. That's where I should have prepared this interview and review the parts for which Rust is well known for but that I haven't used enough.1</a> Beware that those concepts are not specific to Rust but they can be remote when you've spent too much time in higher level languages. The team is composed of top-notch Rust developers and I understand that they are on the other side of the fence: technically precise, with a good understanding of the inner working of the tech they use. That's usually what I strive for but I'm not there (yet?) with Rust. Duality</h2> That made me realize that Rust has two faces: usable for people coming from higher level programming language (like me!) while exposing everything needed to go down and master every aspect of what you're doing. All in all, it has been a great experience, the people I interact with were nice and the process was quite smooth. I didn't expect interviews to be so much fun (yet stressful!). All in all, it made me more curious about the fearless concurrency side of Rust. I can't wait to dive more into it. ^{1 I was so thrown off that I couln't even answer simple questions: what is a mut</code> reference? (yeah, I know... 🙄) How do Kafka and RabbitMQ differ? what is backpressure? </div>} Triathlon training ≈ Startup life 2019-08-29T20:06:36+02:00 I've completed my first triathlon last week and it struck me how similar the journey to the race was to what I'm experiencing in the creation of Bismuth</a>. Starting Point</h2> When you're not an accomplished athlete, signing up for a triathlon is not something you do lightly. I was an avid runner in 2012-2015 but have stopped training since then. I regularly commute by bike (~9km each way) so my legs were still in shape but I've hardly done more than a 20km trip in my life. When a friend asked me to join a small group of wannabe triathletes training for La Gileppe Trophy Orbea</a> it was hard to resist. We would not train for nothing: we had a well-identified goal. This is very different than just aiming for an abstract objective (being a triathlete). The same goes for a startup. Aiming for startup life should not be a goal in itself. You should have a more concrete plan. Team & Network</h2> The social aspect of the endeavour should not be underestimated. We were a group of five guys training for three sports. We were scattered throughout the region (Mons-Brussels-Liège, Belgium) and had only a few trainings together. It made little sense to meet for a one-hour run/swim when you live 2 hours away from each other. We had a couple of longer bike trainings on Sundays though. But not training together did not mean that there was no network effect. Strava</a> logs and a Facebook group conversation are powerful motivation tools. We could greet ourselves when completing an early morning swim session or a late bike ride. The odds that I took my bike for a spin after a long day were a lot greater than if I was alone. It's way too easy to postpone a task when you are the only one in town. Humor and camaraderie work well when you are in doubt and think that you're falling behind. Sharing content and training tricks maintained the interest and made sure we learnt faster. The same goes for a startup team. Being alone is good when you need to be focused on the work but interactions and discussions are important for ideation, motivation and mental health. Planning</h2> Even though we registered for a short distance (triathlon sprint), one of us showed up with an ambitious training plan. It looked a bit too much for me. I knew from the start that I would not be able to follow. And it's alright. Sticking to a training plan you know you cannot follow is a stupid idea. Tune it down until you're confident you can make it. On my side, I hadn't swam for ages and could barely cross the pool without losing my breath. Bike was ok-ish thanks to my commute but longer distances were an unknown territory. Running was my strongest point as I had trail running experience and knew the sensation in the legs and in my brain throughout the effort. Knowing this, I created a plan custom tailored for me. I still don't know if it was optimal. It probably wasn't but it got me through the race without any hiccups so I consider it a win. Execution and unplanned changes</h2> Having the plan is only the beginning. This is something you cannot delegate, you're the one in charge. Here again, the peer pressure of the group is important. You are not accountable to them but you don't want to be the lazy ass that does not do anything. Beware though. I've quickly noticed that social life can make it challenging to follow the plan. Up for a beer and pizza tonight? kind of text will challenge your focus and dedication. There's a balance between turning into a social hermit and going out every night. Keeping the pizza but swapping the beer for sparkling water is the kind of compromise I was willing to make. A recent interview</a> of Katie Arnold showed that with a bit of creativity, you can mix a social life with kids and strong long distance training. At my level, the plan is just a guideline. The goal was not to finish in the top 10, so flexibility was more important than performance. In a startup though, you might aim for more. This is okay but be aware of the impacts on your life. Polyglot</h2> Triathlon or how to be mediocre at three sports </blockquote> Swim, bike and run are different disciplines. Being at least decent in the three of them is the whole game. For me, it was a revelation: it is much more fun to train for three sports than focus on one. In a startup, founders are usually doing a bit of everything. They need to juggle between sales, code, marketing, raising money and more. The result should be a balance between these tasks. Of course, the balance is different at every stage and the founder must quickly react to a new situation. This diversity is extremely challenging but also super fun and rewarding. Learning & staying humble</h2> Starting a new endeavor is always full of lessons. In triathlon training, you learn to listen to your body. You experiment. You learn how you can improve efficiency by adjusting your swimming strokes. You listen to advice (try your wetsuit in open water before race day!). Some are valid in a context but not in another. Keep them in mind though, they could be useful one day. You're the beginner with no experience. With practice, you will build confidence and find your rythm. Be patient but don't be passive. Knowing when to slow down</h2> In the second month of training, a pain in my knee started to develop. I slowed down training and quickly identified that the pain came from running. When cross-training it can be hard to identify a single source of trouble but in my case it was easy: my running shoes had more than 1000km. Fortunately, summer sales are always good to buy new shoes and the problem went away as fast as it appeared. Not taking the time to slow down and identify the issue could have dramatic consequences. The same goes for a startup. You should always listen to your feelings (and to metrics) and adjust properly. Equipment is not that important</h2> Some would believe that you need top-notch equipment to complete a race. This is far from true and the only two technical pieces of equipment you need is a swimming wetsuit</a> and a bike. The bike is by far the most expensive thing you'll need. The best bike to start with is the one you already have. A woman finished the triathlon on a foldable Brompton</a> and a lot of riders had mountain bikes. Find a cheap second hand bike on craigslist and start riding. Nowadays, most startups can be launched without any specific equipment. A laptop and a phone are all you need to get started. You don't need a $3000+ Macbook Pro or an expensive SAP license to get started. Be smart about it and gear up only when you need to. Be hungry for more</h2> This is just the beginning of my triathlon journey. The sprint distance was a nice start but in the end of the race I still had some energy left. This means that training was good enough and that my body and mind were ready. The whole race was fun and a lot of endorphin was released that day. It's time to plan the next one. I'm tempted to go for a longer distance this time. I've started to work full time on Bismuth</a> at around the same time that I started to train for the triathlon. Focusing on both is a challenge and some will say that having two parallel activities both requiring a lot of grit is the best way to waste it. I don't believe it is. On the contrary, I think the two are complementary. On bad days for Bismuth going for a run is a great way to let off some steam. On the other side, an early-swim session is a great way to start the day and is a good reason to jump out of the bed. I can't wait to see how these two will eventually end up! (pictures by Caroline Vermeulen</a> and Lindsay Eeckhaudt</a>) Our Tech Stack: Rust, Typescript, React & Swift 2019-07-17T20:06:36+02:00 tl;dr</h1> Rust (actix-web, Diesel)</li> Swift (SwiftPM, swift-ast)</li> Typescript</li> React (Atlaskit, Redux)</li> AWS (Fargate, PostgreSQL RDS)</li> Terraform</li> </ul> Company Culture</h1> I have a confession to make: I love discussing about tech stacks. They convey values and can tell a lot about company culture and the technical history of a technology team. Of course they don't always tell the whole story: I know a place that emphasises on employee happiness and where COBOL is still king. The holy stack that will solve all your problems does not exist. There is no silver bullet</a>, remember? Instead, you pick the stack that makes the more sense to you, the one you're comfortable with, the one that fits your use case. It might be tempting to go all-in in the latest technologies and niche languages. When I was at the beginning of my career someone wise told me that a new venture should not have more than one new shiny thing in its stack. I believe this is true and that developers are sometimes too attracted to technologies that won't survive the next winter. Bismuth</h1> Bismuth</a> is a service that takes your code, passes it through the mill and shows you where its structure is not ideal. We are still in the early stage and have hundreds of ideas but the end goal is to improve the process of developing software. Not only for developers but also for other stakeholders</a>. We currently focus on mobile apps but the tools and philosophy can be applied to anything. The Tech Stack</h1> Bismuth has four main components: Parsers for languages we support,</li> REST endpoints for API,</li> Workers that process the influx of code,</li> Visualisations engine for user interaction.</li> </ul> Parsers</h2> Parsing source code can be challenging but it's an already solved exercise. Our motto there was not to reinvent the wheel for each programming language and don't roll our own parser. Each environment has its own set of tools that work for them. We probably won't be smarter than them anytime soon. For Swift, we use swift-ast</a>, which happen to be written in Swift. There were other options like using the C++ Swift compiler frontend but our team was mostly familiar with Swift and the library provided everything we needed. For Java and Kotlin, we will probably go with Jetbrains UAST</a> in Kotlin. For Javascript and Typescript there are more options: Esprima</a> (JS), RESSA</a> (Rust), and the Typescript compiler itself. API Endpoints & Workers</h2> We chose Rust</a>. That might sound surprising for a web API: dynamic languages have a good reputation for this type of work but Rust encompasses values that we believe in: Correctness: Rust has a strong tendency to make you do things the right way. Is it very rare that a Rust library reaches the 1.0 version without being really production-ready. </li> Stability: The Rust team is very careful not to break things between releases. That does not mean that they are not moving fast (~6 weeks between releases) </li> Speed: this is less important for us but Rust is quite fast, even compared with C++ or C. </li> Libraries & build: There are tons of libraries ready to be used in the crates.io</a> ecosystem. The build tool cargo</a> feels familiar if you've used Ruby Gems, PHP Composer or Gradle dependencies. </li> All those values reflect in the community. It is helpful, inclusive and newbies are taken care of. </li> </ul> While still being relatively young, Rust ticks a lot of boxes. Software is hard and having a language that promotes good practice feels like a friend holding your hand. It usually takes us a bit longer to write Rust code than to hack a Ruby or JS script but the feeling Rust gives when the code compiles is that it will be correct and that it will stands the test of time. Personally, this is a feeling I hadn't had since my OCaml</a> days. We believe that using Rust is also a strength when hiring new developers. Rust developers are usually sensitive to clean code: their brain has been washed by explicit error handling and a very strict compiler. They might be much harder to find than Java developers but this can be seen as a strength as the odds to attract good developers is probably higher with Rust than Java (flame war fuel here). UI and Visualisation</h2> Typescript</a>/React</a>/Redux</a> is now one of the standard stacks in frontend those days. Unless 4-5 years ago when the JS frontend war was fierce with a new competitor every week, we believe the winners have emerged and that we won't see too much disruption in the few coming years (i.e., React, Angular and Vue.js have won). Our visualisations are built with D3</a>, the de-facto standard for displaying visual data on the web and our GUI is built with Atlaskit</a>. We use this frontend stack both on the web and on our electron</a> app. Electron can be really frustrating to work with at times but it is becoming ubiquitous on the desktop front (if God exists, she will destroy humanity when she sees how we waste our RAM). Infrastructure</h2> All this code sits into one monorepo. This is useful to keep track of everything in one place. On the negative side, it makes CI a bit harder as you have to detect which part of the app was affected. This might be alleviated by using Bazel</a> to build every components of our systems but we are not there yet. We deploy on AWS using Terraform</a>. We had no experience either with AWS or Terraform but the documentation is good enough and it is quite easy to find support. Who doesn't have someone who knows AWS in their circle these days? We use RabbitMQ</a> for messaging between all our components. We're very far from reaching its limit and it serves us well so far. Future</h2> We don't know yet how the future will look like but we believe our stack is solid enough to withstand it. Time will tell ;) Build mobile apps with Bazel. Part 2: iOS 2018-07-20T10:39:54-04:00 After building an Android app and its dependencies with Bazel</a> in the first post of the series</a>, we continue our journey by adding an iOS app to our monorepo. Read the first post</a> if you want to have more context about what we are trying to achieve and why we use a monorepo and Bazel to build mobile apps. In this second post, we will see how we can express internal and external dependencies, how to organise the monorepo directories and how to run the app with XCode. Directory structure</h2> We will mirror the code organization we had for the android app: AppA-iOS</li> Lib-iOS</li> </ul> Those two directories sit right next to their android counterpart. Current situation overview</h2> Bazel has built-in support for Apple platforms</a>. Almost all iOS developers use XCode to build their apps. The tricky part is that XCode is not extensible and very rigid in the way it manages a project. All the configuration is stored in an xcodeproj</code> file. Multiple projects can be combined in an xcworkspace</code>. The chance of Apple supporting Bazel is close to zero and that won't change any time soon. That is why Tulsi</a> is born. It will generate xcodeproj</code> files based on the Bazel description of a build. A popular tool in the iOS world is CocoaPods</a>: CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over 48 thousand libraries and is used in over 3 million apps. CocoaPods can help you scale your projects elegantly. </blockquote> Almost all the libraries targeting iOS are available as a Pod. Converting a Podfile</code></a> to a BUILD</code> file feels a bit clunky but is usually trivial if the dependency list is short. If the pod is written in Objective-C, it is possible to directly declare the pod dependency with PodToBUILD</a> without any manual process. AppA-iOS</h2> The official documentation has a tutorial</a> to create an iOS project. It is maybe a bit outdated so it might be better to directly read the git repo of the apple rules</a>. We first import the Bazel rules in our WORKSPACE</code> file: git_repository( name = "build_bazel_rules_apple", remote = "https://github.com/bazelbuild/rules_apple.git", tag = "0.6.0", ) load( "@build_bazel_rules_apple//apple:repositories.bzl", "apple_rules_dependencies", ) apple_rules_dependencies() </code></pre> Nothing really fancy here, we add the Apple rules repo and load them. We are now ready to create the app: $ mkdir AppA-iOS $ touch AppA-iOS/BUILD </code></pre> AppA-iOS/BUILD</code>: load("@build_bazel_rules_apple//apple:ios.bzl", "ios_application") load("@build_bazel_rules_apple//apple:swift.bzl", "swift_library") swift_library( name = "Sources", srcs = glob(["src/**"]), resources = [ "Resources/Main.storyboard", ], ) ios_application( name = "AppA-iOS", bundle_id = "be.tulipemoutarde.appa", families = ["iphone"], infoplists = [":Info.plist"], visibility = ["//visibility:public"], deps = [":Sources"], ) </code></pre> An interesting pattern here is that the ios_application</code> rules does not reference the source code. Instead, all our code is bundled into a swift library on which the app depends. We create a plist.info</code>, AppDelegate.swift</code> and Main.storyboard</code>. They don't do much but we want to have a buildable app as soon as possible: AppA-iOS/src/AppDelegate.swift</code>: import UIKit @UIApplicationMain class AppDelegate: NSObject, UIApplicationDelegate { var window: UIWindow? func application(_ application: UIApplication, didFinishLaunchingWithOptions: [UIApplicationLaunchOptionsKey : Any]?) -> Bool { print("App has started") return true } } </code></pre> AppA-iOS/Info.plist</code> (nothing interesting in here, don't write this by hand, get it from an existing project): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>LSRequiresIPhoneOS</key> <true/> <key>UIMainStoryboardFile</key> <string>Main</string> <key>UIRequiredDeviceCapabilities</key> <array> <string>armv7</string> </array> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> </dict> </plist> </code></pre> AppA-iOS/Resources/Main.storyboard</code> (nothing interesting in here, don't write this by hand, use XCode to generate/edit the Storyboard): <?xml version="1.0" encoding="UTF-8"?> <document type="com.apple.InterfaceBuilder3.CocoaTouch.Storyboard.XIB" version="3.0" toolsVersion="11542" systemVersion="16D32" targetRuntime="iOS.CocoaTouch" propertyAccessControl="none" useAutolayout="YES" useTraitCollections="YES" colorMatched="YES" initialViewController="BYZ-38-t0r"> <device id="retina4_7" orientation="portrait"> <adaptation id="fullscreen"/> </device> <dependencies> <deployment identifier="iOS"/> <plugIn identifier="com.apple.InterfaceBuilder.IBCocoaTouchPlugin" version="11524"/> <capability name="documents saved in the Xcode 8 format" minToolsVersion="8.0"/> </dependencies> <scenes>  <scene sceneID="tne-QT-ifu"> <objects> <viewController id="BYZ-38-t0r" sceneMemberID="viewController"> <layoutGuides> <viewControllerLayoutGuide type="top" id="y3c-jy-aDJ"/> <viewControllerLayoutGuide type="bottom" id="wfy-db-euE"/> </layoutGuides> <view key="view" contentMode="scaleToFill" id="8bC-Xf-vdC"> <rect key="frame" x="0.0" y="0.0" width="375" height="667"/> <autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/> <subviews> <label opaque="NO" userInteractionEnabled="NO" contentMode="left" horizontalHuggingPriority="251" verticalHuggingPriority="251" text="Hello from Bazel" textAlignment="natural" lineBreakMode="tailTruncation" baselineAdjustment="alignBaselines" adjustsFontSizeToFit="NO" translatesAutoresizingMaskIntoConstraints="NO" id="Z9g-BR-NKm"> <rect key="frame" x="143" y="323" width="89" height="21"/> <fontDescription key="fontDescription" type="system" pointSize="17"/> <nil key="textColor"/> <nil key="highlightedColor"/> </label> </subviews> <color key="backgroundColor" red="1" green="1" blue="1" alpha="1" colorSpace="custom" customColorSpace="sRGB"/> <constraints> <constraint firstItem="Z9g-BR-NKm" firstAttribute="centerX" secondItem="8bC-Xf-vdC" secondAttribute="centerX" id="b9H-lm-x4b"/> <constraint firstItem="Z9g-BR-NKm" firstAttribute="centerY" secondItem="8bC-Xf-vdC" secondAttribute="centerY" id="uTp-aY-7lJ"/> </constraints> </view> </viewController> <placeholder placeholderIdentifier="IBFirstResponder" id="dkx-z0-nzr" sceneMemberID="firstResponder"/> </objects> </scene> </scenes> </document> </code></pre> To recap, this is what our directory structure looks like: $ tree -L 7 AppA-iOS/ AppA-iOS/ ├── BUILD ├── Info.plist ├── Resources │ └── Main.storyboard └── src └── AppDelegate.swift </code></pre> We can now check that all the dots are connected together: $ bazel build //AppA-iOS </code></pre> If all goes well, you should have the bazel-bin/AppA-iOS/AppA-iOS.ipa</code> file. This is the app bundle. You must sign it before you can send it to a device. This is where the experience starts to become cumbersome: we will generate an XCode project to launch the app. Using XCode with Tulsi</h2> Time to install Tulsi</a>, a tool made by the bazel team to generate XCode projects from Bazel definitions. There are no pre-built binaries, you must compile it yourself. It's pretty straightforward and it should build cleanly without any modifications. Tulsi will generate a .tulsiproj</code> directory containing all your configuration. I placed the tulsiproj file next to the WORKSPACE</code> file and let it in git. Add /tulsigen-*</code> and /tulsi-*</code> to the root .gitignore</code> (like the /bazel-*</code> symlinks). It seems that having a single tulsiproj file for all your monorepo is the way to go. You can add all your bazel packages and config into it. I haven't used it in a real project so this might be wrong. Only experience will tell. Beware that XCode might not behave like you are used to. The BUILD</code> file is the single source of truth for building. Do not trust what you see in XCode. Compilation flags should be set in Bazel, not XCode. Adding a file in XCode will not include it in your build. For example, if you add a file to the sources, you must regenerate the xcodeproj if you want to see it in XCode. xcodeproj are just a transient container to use Apple tools on our code. I've decided not to version them (*.xcodeproj/</code> in .gitignore</code>). I don't know yet if it is the best thing to do, again only experience will tell. Let's recap our directory layout: {{<highlight shell "hl_lines=6-7 12">}} [EDITED FOR CLARITY] $ tree -L 7 . . ├── App-A-Android ├── AppA-iOS │ ├── AppA.xcodeproj │ │ ├── ... Xcode proj junk │ ├── BUILD │ ├── Info.plist │ ├── Resources │ └── src ├── BazelApps.tulsiproj │ ├── Configs │ │ └── AppA.tulsigen │ ├── fstephany.tulsiconf-user │ └── project.tulsiconf ├── Lib-Android ├── README.md ├── WORKSPACE {{</highlight>}} Internal Swift library</h2> Pure Swift code can run on both macOS and Linux. Bazel can handle both and will happily build Swift code even when it is not tied to iOS/macOS. The bazel team is reworking to unify Swift rules under a new repo: rules_swift</code></a>. It is a work in progress and unfortunately, we can't use </code>rules_appleand</code>rules_swift` in the same dependency tree yet (as of 0.6.0</a> and 0.2.0</a> respectively). So we'll us the swift_library</code> of the rules_apple</code> instead of the one in rules_swift</code> but that might change in a near future. We create a Lib-Swift</code> directory and create the BUILD</code> file: load("@build_bazel_rules_apple//apple:swift.bzl", "swift_library") swift_library( name = "Lib_Swift", srcs = glob(["src/**"]), visibility = ["//visibility:public"], module_name = "AppLib", ) </code></pre> And here we hit a annoyance: the name of the artifact does not match the name of the directory. This is because swift target names are limited to [a-zA-Z0-9_]</code>. The module_name</code> param is important as it will be the name of the generated Swift module (i.e., the one you will import). We add dummy swift code to our library: Lib-Swift/src/StringProvider.swift</code>: public class StringProvider { let baseString: String public init(baseString: String) { self.baseString = baseString } public func provideString() -> String { return "\(baseString) was the base string" } } </code></pre> And check that it builds: $ bazel build //Lib-Swift:Lib_Swift </code></pre> Time to use this new library in our main app: AppA-iOS/BUILD</code>: {{<highlight python "hl_lines=10">}} load("@build_bazel_rules_apple//apple:ios.bzl", "ios_application") load("@build_bazel_rules_apple//apple:swift.bzl", "swift_library") swift_library( name = "Sources", srcs = glob(["src/**"]), resources = [ "Resources/Main.storyboard", ], deps = ["//Lib-Swift:Lib_Swift"] ) ios_application( name = "AppA-iOS", bundle_id = "be.tulipemoutarde.appa", families = ["iphone"], infoplists = [":Info.plist"], visibility = ["//visibility:public"], deps = [":Sources"], ) {{</highlight>}} AppA-iOS/src/AppDelegate.swift</code>: {{<highlight swift "hl_lines=2 12-13">}} import UIKit import AppLib @UIApplicationMain class AppDelegate: NSObject, UIApplicationDelegate { var window: UIWindow? func application(_ application: UIApplication, didFinishLaunchingWithOptions: [UIApplicationLaunchOptionsKey : Any]?) -> Bool { print("App has started") let provider = StringProvider(baseString: "Hello") print("\(provider.provideString())") return true } </code></pre> } {{</highlight>}} We can build the app again to check that everything is OK: $ bazel build //AppA-iOS </code></pre> When opening the XCode project, it will build and run fine but won't show the source code of the AppLib</code> module. We need to regenerate the xcodeproj file: First add the package to the project.</li> </ol> Add it to the config and add a target</li> </ol> Regenerate the XCode project and open it</li> </ol> Xcode now knows everything about the code and we can navigate easily in the app and lib code. External CocoaPod library</h2> Many iOS apps load external libraries for common tasks. Carthage</a> and CocoaPods</a> are the most common tools to handle those dependencies. As an example, we will import the RxSwift</a> and RxCocoa libraries into our project. Manual Pod conversion</h3> The official doc for converting CocoaPods depedencies to Bazel</a> is a bit disappointing. The process is tedious: manually examine the Podfile</a> and Podspecs</a>;</li> download each Podspec (beware of version numbers!) and create a BUILD for each</li> Modify the main BUILD file to express the dependency.</li> </ul> Don't worry if you find these instructions confusing, we'll see how this translates to RxSwift/RxCocoa. If you don't want to deal with a manual process and work with Objective-C pods, skip to the PodToBUILD section. RxSwift</h4> We see in the RxSwift Podspec</a> that it does not have any external depencies. This will make our task easier. We will start by adding the RxSwift code as an http archive in our WORKSPACE</code>: new_http_archive( name = "Rx", url = "https://github.com/ReactiveX/RxSwift/archive/4.2.0.tar.gz", strip_prefix = "RxSwift-4.2.0", sha256 = "d8474e9733075e7164732b25284c263d0b16e9c9a18393de932bd8ddded73360", build_file = "Pods/RxSwift/BUILD") </code></pre> The archive path was retrieved from the release page of RxSwift on Github. The SHA signature is not mandatory but it's a first verification step to ensure that you are grabbing the right archive. To be sure to have reproducible builds, you might want to store the archive file on a location you control. An obvious downside of hardcoding the version is that we lose the ability to update the external dependencies automatically with the build tool. Some will see this vendoring (i.e., the act of copying an external dependency into the source tree. Completely bypassing the original location of this dependency) as an advantage, some as an evil thing. Choose your side but be pragmatic about it. The strip_prefix</code> argument is handy because the downloaded archive has a top level directory RxSwift-4.2.0</code> containing everything. As our BUILD file contains relative paths to the archive content, strip_prefix</code> will save us a few key strokes. Finally, build_file</code> contains the path containing the BUILD file we'll use to build stuff from this archive. Pods/RxSwift/BUILD</code>: load("@build_bazel_rules_apple//apple:swift.bzl", "swift_library") swift_library( name = "RxSwift", module_name = "RxSwift", srcs = glob( ["Platform/**/*.swift", "RxSwift/**/*.swift"], exclude= ["RxSwift/Platform/**/*.swift"] ), visibility = ["//visibility:public"], ) </code></pre> The srcs</code> directories are a copy-paste from the RxSwift podspec</code></a>`. As the Rx</code> entity is an external one, we must refer to it with a @</code> (we saw that in the first post</a>). $ bazel build @Rx//:RxSwift </code></pre> Add this dependency to the main app: AppA-iOS/BUILD</code>: {{<highlight python "hl_lines=12">}} load("@build_bazel_rules_apple//apple:ios.bzl", "ios_application") load("@build_bazel_rules_apple//apple:swift.bzl", "swift_library") swift_library( name = "Sources", srcs = glob(["src/**"]), resources = [ "Resources/Main.storyboard", ], deps = [ "//Lib-Swift:Lib_Swift", "@Rx//:RxSwift" ] ) ios_application( name = "AppA-iOS", bundle_id = "be.tulipemoutarde.appa", families = ["iphone"], infoplists = [":Info.plist"], visibility = ["//visibility:public"], deps = [":Sources"], ) {{</highlight>}} AppA-iOS/src/AppDelegate.swift</code>: {{<highlight python "hl_lines=3 8 17-23">}} import UIKit import AppLib import RxSwift @UIApplicationMain class AppDelegate: NSObject, UIApplicationDelegate { let disposeBag = DisposeBag() var window: UIWindow? func application(_ application: UIApplication, didFinishLaunchingWithOptions: [UIApplicationLaunchOptionsKey : Any]?) -> Bool { print("App has started") let provider = StringProvider(baseString: "Hello") print("\(provider.provideString())") Observable .just(1) .subscribe( onNext: { print("Emitted \($0)")}, onCompleted: { print("Stream has completed") } ) .disposed(by: disposeBag) return true } </code></pre> } {{</highlight>}} And that's about it, RxSwift is now working in the project. Unfortunately, it does not seem possible to see its source code in XCode. When adding the Pods/RxSwift/BUILD</code> as a package in tulsi, it as a package in Tulsi, it cannot find the associated source code. Which is quite understandable as this BUILD file should be interpreted within the context of the new_http_archive</code>. I haven't found an elegant solution yet. If you have an idea, ping me</a>. But the app builds fine (even in XCode). RxCocoa</h4> RxCocoa depends on RxSwift but is hosted in the same git repo. Its podspec</a> is not really an issue and is easily mapped into Pods/RxSwift/BUILD</code>: {{<highlight python "hl_lines=15-26">}} load("@build_bazel_rules_apple//apple:swift.bzl", "swift_library") Based on RxSwift.podspec</h1> swift_library( name = "RxSwift", module_name = "RxSwift", srcs = glob( ["Platform//*.swift", "RxSwift//.swift"], exclude= ["RxSwift/Platform/**/.swift"] ), visibility = ["//visibility:public"], ) Based on RxCocoa.podspec</h1> swift_library( name = "RxCocoa", module_name = "RxCocoa", srcs = glob( ["Platform//*.swift", "RxCocoa//.{swift,h,m}"], exclude= ["RxCocoa/Platform/**/.swift"] ), deps = [":RxSwift"], visibility = ["//visibility:public"], ) {{</highlight>}} Building RxCocoa is no different: $ bazel build @Rx//:RxCocoa </code></pre> Declare Pod dependency with PodToBUILD</h3> Manually converting a Pod is not always necessary as PodToBUILD</a> will take care of it. It is written by Pinterest and supports Objective-C Pods. Future</h2> The rules_swift</code></a> is slowly replacing the rules_apple</code></a> for building Swift code. The new rules should work on Linux and will probably the way to go in the future. In the meantime, rules_apple</code> works pretty well. Conclusion</h2> Adding an iOS app and library to the monorepo was not really hard. Dealing with external libraries still requires some hand written config to map the CocoaPod (or Swift Package) definitions. Fortunately, most of them are trivial. When Pods are in Objective-C, PodToBUILD</a> makes it easy to integrate them in the BUILD</code> file. As before, you can check the source code on Github</a>. So far we have two completely distinct worlds where iOS and Android live next to each other but don't share any code. This will be the topic of the next post in the series. As usual, ping me on twitter</a> if you have any feedback, suggestion or question. Update: Many thanks to @rmalik</a> and @jin_</a> for reaching out</a> to let me know about PodToBUILD. Build mobile apps with Bazel. Part 1 2018-06-02T20:06:36+02:00 (Update: The second part on building the iOS app is now available</a>)) These days, I work a lot on software architecture and code reuse among projects and among platforms. In this blog post I will explore a way to oragnize source code to deal with the complexity of cross platform development. We will build a small sample project on Android and iOS with Bazel</a> and a monorepo. You can get the code related to this blog post on Github</a>. Browse the tags</a> to see the different steps. Multi-platform mobile apps</h2> One of the fallacies of mobile app development is the schism between Android and iOS. To go the native route, an app need two different codebases: one in Java/Kotlin for Android and one in Objective-C/Swift for iOS. Both require different knowledge and different tools resulting in two different teams where you could/should have one. Bugs are also duplicated and business logic is not canonical; there might be subtle differences in behavior between the apps. Cross platform frameworks</h3> To solve this problem, cross-platform frameworks have appeared. They have matured the past five years and they probably fill 80% of the common needs. Some completely abstracts the underlying platform (e.g., React Native, Flutter) while others still provide a first-class access to the native SDKs (e.g., Xamarin). They usually still sit on top of the native languages of the platforms. They provide hook to enter in the native world of Android and iOS. They are no silver bullet though. Those frameworks have their quirks and sometimes you have to dig in and work with the native SDK. Debugging can also be a problem: is the bug in your code, in the cross platform framework or in the native one? It is a good idea to still have people who understand each platform and their associated tools. They can also lag behind the official SDK. How fast do they integrate changes from Apple and Google in the official distribution? This blog post won't use any of those framework. Expect a blog post in the future to know how and when they can shine and how/when they suck. Good old C to the rescue</h3> Another trend is to use the lingua franca of the programming languages: the C ABI. Most platforms can load and call libraries coded in C/C++. Mobile developers can leverage that situation and build cross-platform code that will work everywhere. And by everywhere, iOS and Android are not the only target; the gates are open to Windows, Linux, macOS and with the recent surge of WebAssembly, web browsers are also in the visor. Slack</a>, Dropbox</a>, and Microsoft</a> uses this approach for their cross platform apps. Tools exist to help. For example Djinni</a> (developed by Dropbox) is a tool that will generate the glue between C++ code and Objective-C/Java code from an IDL (Interface Description Language) file that describes your data structures and functions. You can call one side from the other, djinni handles the conversion. When you think about it, C and C++ are not the only languages that can expose a C ABI-compatible library. Rust and Chicken Scheme can do that as well and might be well suited to your needs. One of the biggest limitation of this approach is that you usually still need the native language of the platform to interact with platform-specific APIs: User Interface, Notifications, etc. You can share all the business logic code but you still need some entry points for the platform APIs. A real-world example</h2> Imagine the (not so) hypothetical case where we have two apps that we ship on the app store. If we release them on the two most common platforms, iOS and Android, we end up with 4 different codebases. As some of the features are similar between the two apps, we develop libraries to host the common code (some business logic, some UI/grapics elements): It's already better. Especially if we had a third or fourth app. We can now add a third layer that will be common to all the apps: The last layer could contain a lot of stuff: database access, network requests, business logic, etc. With more effort we can even imagine that our ViewModels</code> would be shared between platforms. The small platform-specific layer between the lib and the Apps could be bindings automatically generated. For this blog post, we'll stop at the second stage: different libs for each platform. Multiple git repos</h3> It is common among developers and dev shops to have separate repos for different apps/libs. In our case, that gives 6 git repos: AppA-iOS </li> AppA-Android</li> AppB-iOS</li> AppB-Android</li> Lib-iOS</li> Lib-Android</li> </ul> Lib-iOS and Lib-Android versioning</h3> A solution for the libs is to version them and add them as a dependency to our apps. For iOS, CocoaPod</a> is probably the most common way to generate a package. This means we need a private PodSpec repo to keep track of the versions. That makes 7 git repos. The same goes for the Lib-Android, we might want to have a git repo acting as a Maven repository (e.g., with GitWagon</a>). We now have 8 git repos. The iOS and Android libs don't share any code yet, they are pure-Swift and pure-Kotlin code implementing the same set of feature. It's still better than not having a common lib for AppA and AppB as we have two duplicates instead of four. Lib is used by both AppA and AppB. What if we make a breaking change into the Lib? This is where semantic versioning</a> is important and you should have enough discipline not to break it. Unfortunately, it is quite hard to enforce automatically. When working on the libs, we probably want to test changes in the context of AppA and AppB. We don't want to publish a new version until we know that the changes are correct. So we need a way to tell our build system to use the local (i.e., on the developer disk) version of the lib or the published version for building AppA and AppB. We can do that with buildVariant on Android and by fiddling with the Podfile/target on iOS but it can also be error prone. Now if we work on a feature that requires changes in both the Lib and an App, the branches for both projects should be created and checkouted in sync. What happens if a developer starts to work on a feature on AppA and forget to change branch in the Lib? By experience, it is quite common to make a change in the Lib, update AppA, forget about AppB and let it in a broken state. The CI (if we're lucky to have one) will catch the error but the harm is done: wasted energy. Build tools</h3> By default, iOS apps are built with xcodebuild, Android apps with Gradle. If we have libraries written in Rust, we'll need Cargo and if we have C libraries we'll need CMake (or anything that can build C). Tying all those build tools together can be quite challenging, especially when expressing dependencies. Overall, working on that many different git repositories is a mess. It requires a lot of discipline and developer attention. If you develop a small app or does not require a lot a reuse this model works perfectly fine. I've used it for many years while developing Ruby On Rails app which tended to be self contained. But once you reach a certain threshold on certain kind of projects, it is simply painful. Bazel and the monorepo</h2> That's where a monorepo and Bazel come in. With those, we'll throw our packaging systems and use a unified build system. Actually we might still need them, the ecosystems around CMake/Gradle/Cocoapod/xcodebuild are too pervasive to ignore. When developing an app, it is quite common to rely on 3rd party libraries that are packaged with the native tools of the platform. We'll go the full route and use a monorepo. Our previous git repositories will be merged into one. Each previous repo will be a top level directory in the new one. This might sound crazy (or event heretic) but stick with me here. Bazel</h3> Blaze is a build system initially developed internally at Google. They open sourced it in 2015 under the name Bazel</a>. Developers that left Google before Blaze was open source were so fond of it that they re-developed it to build stuff at the companies they were joining. That's how Buck</a> (by Facebook) and Pants</a> (by Twitter) were born. Today, Bazel is widely used and can build a lot of different languages Uber, Dropbox, Etsy, Huawei, Stripe, SpaceX, Pinterest and many others are building software with it (links at the bottom of the post). Conceptually Bazel is quite simple. You have a WORKSPACE</code> file at the top of your project. This is where you'll load and configure all the rules you'll need to build your project. There are official rules for a lot of different stacks (e.g., C/C++, Java, Android, Go, Kotlin). In every directory containing a buildable artifact you'll have a BUILD</code> file. It describes where the files to compile are, the dependencies you need and other configuration options like the visibility of the build output. And that's basically it. Bazel will build the dependency graph and aggressively cache the artifacts that have already been built. That's why you want to have a lot of small modules instead of a big one containing everything. Bazel encourages you to keep everything small and compose your code from smaller parts. A side effect of this layout is that someone modifying a library must ensure that all the parts that depend on it are not broken. Bazel has a query system to let you see the impact of modifying one unit of code. As everything is in the same repo, the developer has everything she needs to ensure that the build is not broken. She doesn't need the discipline to create a branch for each repo affected by the feature she's working on as everything is in the same place. When the provided rules are not enough, it is possible to code your own using Skylark</a>, a language derived from Python. All of this is well in theory but in practice, how does it work? Initial setup</h3> We will create a small Android App that displays a string from a Java lib. In future post, we will add a C library that will be called with JNI. We will then add more complex data structure and iOS to the mix. You can follow the whole project on this Github repository</a>. Create a single top-level directory for all our code. This directory will be versioned in a unique Git repo. Feel free to use any other VCS. It does not really matter at this point. Create a WORKSPACE</code> file. This file will inform Bazel of all the tools we need to build the code. Create AppA-Android</h3> Add the Android SDK to the WORKSPACE</code> file: WORKSPACE</code> load("@bazel_tools//tools/build_defs/repo:maven_rules.bzl", "maven_aar") android_sdk_repository( name = "androidsdk", api_level = 27, build_tools_version = "27.0.3", ) </code></pre> This first instruction makes the maven_aar</code> rules available. It is useful to handle android libraries in the .aar</code> format. The second one tells bazel the configuration of the Android SDK that we want to use. Android usage is fully documented on the official website</a>. All the possible options are listed under the Android Rules</a>.Ensure that you have your $ANDROID_HOME</code> environment variable correctly setup so Bazel can pick the android tools (see the android doc</a>) We can now create the android app. Beware that we don't use the typical Gradle layout but a very barebone one: $ tree -L 7 App-A-Android/ App-A-Android/ ├── BUILD └── src └── main ├── AndroidManifest.xml ├── java │ └── be │ └── tulipemoutarde │ └── appa │ └── MainActivity.java └── res ├── drawable │ └── ic_launcher_background.xml ├── layout │ └── activity_main.xml ├── all-the-mipmap-folders └── values ├── colors.xml ├── strings.xml └── styles.xml </code></pre> You'll notice the BUILD</code> file right under the App-A-Android</code> folder. It describes how to build this particular artifact: App-A-Android/BUILD</code> android_binary( name = "AppA-Android", custom_package = "be.tulipemoutarde.appa", manifest = "src/main/AndroidManifest.xml", srcs = glob(["src/main/java/**"]), resource_files = glob(["src/main/res/**"]), visibility = ["//visibility:public"], ) </code></pre> Nothing really fancy here, it should be readable. Note that the name</code> property (AppA-Android in our case) will be used to identify the entity when building it or when referencing it. Once again, the full documentation for android_binary</code></a> is available. We can now check if we can build the project: $ bazel build //App-A-Android:AppA-Android </code></pre> If you have a device plugged in or a simulator running, you can directly launch the app on it: $ bazel mobile-install //App-A-Android:AppA-Android </code></pre> mobile-install</code> has a myriad of ptions</a> that you can use to customize the launch of the app (e.g., cold start, incremental updates). Add external library</h3> Almost all Android apps use external libraries to perform various actions. Developers can express the dependencies in the gradle build file. Dependencies are usually shipped as regular jar</code> archive or as aar</code> if they ship with resources. Bazel supports both of them natively. We will add Timber</a>, a small log library to our project. We first need to add the library to our WORKSPACE. Doing so will make it available for all the BUILD files: WORKSPACE</code>: load("@bazel_tools//tools/build_defs/repo:maven_rules.bzl", "maven_aar") maven_aar( name = "timber", artifact= "com.jakewharton.timber:timber:4.7.0" ) </code></pre> The first instruction will load the Bazel maven rules and the second will actually point to the external dependency. App-A-Android/BUILD</code>: {{<highlight python "hl_lines=8-10">}} android_binary( name = "AppA-Android", custom_package = "be.tulipemoutarde.appa", manifest = "src/main/AndroidManifest.xml", srcs = glob(["src/main/java/"]), resource_files = glob(["src/main/res/"]), visibility = ["//visibility:public"], deps = [ "@timber//aar", ], ) {{< / highlight >}} Notice how the deps</code> param got a reference to Timber. In this case, the dependency is an aar package but it could have been a java lib that is in your monorepo. The monorepo and Bazel are well suited to code that does not depend on a lot of external dependencies. Google probably has a lot of internal code to perform various tasks while smaller companies probably depends more on external libraries. We can now import Timber in our code and check that everything builds fine: MainActivity.java</code>: // .../... import timber.log.Timber; import static timber.log.Timber.DebugTree; // .../... protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Timber.plant(new DebugTree()); setContentView(R.layout.activity_main); } </code></pre> Note that we've imported the external dependency in the WORKSPACE file and refer to it in the BUILD file. The resulting code is visible as a tag in the sample project</a>. Add Google Maven repository</h3> Since Android Studio 3.0, Google distributes android libraries through a dedicated Maven repo</a>. Unfortunately it does not to work natively with Bazel. The gmaven rules</a> is a temporary (?) workaround to alleviate this issue. It feels like a ugly hack but it works. gmaven_rules manually hardcodes all the libraries provided by Google in its maven repository in a single file</a>. This means the code has to be updated if you need the latest version of the libs. Add the following in WORKSPACE</code>: {{}} GMAVEN_TAG = "20180513-1" http_archive( name = "gmaven_rules", strip_prefix = "gmaven_rules-%s" % GMAVEN_TAG, url = "https://github.com/bazelbuild/gmaven_rules/archive/%s.tar.gz" % GMAVEN_TAG, ) load("@gmaven_rules//:gmaven.bzl", "gmaven_rules") gmaven_rules() {{</highlight>}} Check the gmaven_rules releases page</a> to find the right GMAVEN_TAG</code> to use when you read this. Once the WORKSPACE has the gmaven_rules, we can use them in the BUILD file of our android app: App-A-Android/BUILD</code>: {{<highlight python "hl_lines=1 12">}} load("@gmaven_rules//:defs.bzl", "gmaven_artifact") android_binary( name = "AppA-Android", custom_package = "be.tulipemoutarde.appa", manifest = "src/main/AndroidManifest.xml", srcs = glob(["src/main/java/"]), resource_files = glob(["src/main/res/"]), visibility = ["//visibility:public"], deps = [ "@timber//aar", gmaven_artifact("com.android.support:appcompat-v7:aar:27.1.1"), ], ) {{</highlight >}} We can now extends AppCompatActivity</code> instead of the Activity</code>: {{}} package be.tulipemoutarde.appa; import android.os.Bundle; import android.support.v7.app.AppCompatActivity; import timber.log.Timber; import static timber.log.Timber.DebugTree; public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Timber.plant(new DebugTree()); setContentView(R.layout.activity_main); } } {{</highlight>}} We can now build an Android app with dependencies on both Google and external libraries. Check the git tag on example repo</a> if needed. Create Lib-Android</h3> This is getting interesting. We will add a library inside our monorepo. This library will be available for any BUILD file in the whole repo. We create a new folder that will contain all our code: $ROOT/Lib-Android</code>. Once again, we need to tell Bazel how to build the library in the BUILD file. Lib-Android/BUILD</code>: android_library( name = "Lib-Android", srcs = glob(["src/**"]), visibility = ["//visibility:public"], ) </code></pre> The visibility parameter tells Bazel that we want the artifact to be available everywhere. As we want to reuse this library in the main Android app, it should be visible. Our Java code is pretty simple. Lib-Android/src/be/tulipemoutarde/lib/StringProvider.java</code>: package be.tulipemoutarde.lib; public class StringProvider { private String baseString; public StringProvider(String baseString) { this.baseString = baseString; } public String getAugmentedString() { return "Processed " + baseString; } } </code></pre> We can now build the lib in isolation: $ bazel build //Lib-Android </code></pre> Note that this time we didn't specify the name of the artifact to build. This is because the identifier given to the lib matches the folder name. We couldn't do this with the android app because the folder is named App-A-Android</code> while the app identifier is AppA-Android</code> (notice the extra -</code>). We can now add the library as a dependency to the main app: {{<highlight python "hl_lines=11">}} load("@gmaven_rules//:defs.bzl", "gmaven_artifact") android_binary( name = "AppA-Android", custom_package = "be.tulipemoutarde.appa", manifest = "src/main/AndroidManifest.xml", srcs = glob(["src/main/java/"]), resource_files = glob(["src/main/res/"]), visibility = ["//visibility:public"], deps = [ "//Lib-Android", "@timber//aar", gmaven_artifact("com.android.support:appcompat-v7:aar:27.1.1"), ], ) {{</highlight>}} Ugh. All the deps are written differently. //Lib-Android</code> is the simplest. //</code> represents the root of the project where the WORKSPACE file lies. We simply reference the path and name of the internal dependency.</li> @timber//aar</code> is already a bit different. The @</code> means that we reference an external dependency. //aar</code> tells we want the aar variant of this dependency.</li> Finally, gmaven_artifact()</code> is defined when we imported the gmaven_rules. It will convert the Gradle dependency notation to match the full bazel name given by the gmaven_rules.</li> </ul> Finally we can use the code in our Activity: {{<highlight java "hl_lines=16-17 3">}} package be.tulipemoutarde.appa; import be.tulipemoutarde.lib.StringProvider; import android.os.Bundle; import android.support.v7.app.AppCompatActivity; import timber.log.Timber; import static timber.log.Timber.DebugTree; public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Timber.plant(new DebugTree()); setContentView(R.layout.activity_main); StringProvider provider = new StringProvider("Bazel"); Timber.d("Got an augmented string %s", provider.getAugmentedString()); } </code></pre> } {{</highlight>}} We can now re-build the app: $ bazel build //App-A-Android:AppA-Android </code></pre> Bazel is smart enough to know when to recompile the lib. As usual, you'll find the sample project at this stage under a git tag</a>. Testing</h3> Android Instrumentation Tests are still experimental in Bazel. They were introduced in 0.12 and are maybe still a moving target. The documentation</a> has a step by step tutorial, we won't go through it at the moment. The only downside is that we need to create a dummy android app if we want to test the library in isolation of the main app in an instrumentation test. This is also true when using Gradle. General feeling and conclusion</h2> It is the first time I use Bazel and my impressions are mixed. It feels really robust and forces the developers to think in small modules that you can mix and match together. Bazel assumes that all your dependencies are available in-house. This is certainly true for companies like Google but not for smaller ones. Dealing with external dependencies feels alien. There are projects to generate rules from native tools but they feel clunky (I'm looking at you gmaven_rules()). If your language of choice has a standard tool for dependency management (e.g., NPM, Bundler, CocoaPod, Cargo), you will need some duct tape to integrate it into Bazel. It is not that bad but certainly something to check if you plan to switch to Bazel. The monorepo setup is quite frankly a game changer for at least one of my current clients. Not all the projects I work on would benefit from it but it's a new tool that I'm happy to have in my toolbox. I believe that a shop developing for a single platform (e.g., iOS) could benefit from Bazel. If you have 4 or 5 apps in the App Store, they are good chances that you have some code that you reuse among all of them. Some people uses symlinks and/or git submodules to deal with the situation. If it is your case, you might want to investigate Bazel to see if it could handle your workflow. In the following blog posts we will: Create a Lib in C and use it from the Android App (expect other shenanigans in the deps declaration)</li> Create an iOS App and Lib</li> IDE Support (both Android Studio and Xcode)</li> Pass data structures between C/C++ and Kotlin/Java</li> Use Rust instead of C/C++</li> </ul> If I find the time and the motivation, I would like to cover some other cases: Build a React Native app</li> Build an Electron app</li> Build a JavaFX app</li> </ul> I'm exploring Bazel as I write this series so I probably missed a few things. Please ping me</a> if you have any remark or question. ([Update] The second part on building the iOS app is now available</a>)) References</h2> Uber monorepo iOS</a> (Mar 6, 2017)</li> Uber monorepo Android</a> (May 11, 2017)</li> Dan Luu monorepo blog post</a> (May 2015)</li> Alex Eagle, Angular Monorepo</a> (Oct 18, 2017)</li> Pinterest tips & trick talk</a> (Video)</li> Bazel at Dropbox</a> (Video)</li> Bazel at SpaceX</a> (Video)</li> </ul> About 2018-01-12T10:59:57+01:00 I'm Francois and I'm interested in how we build software. After years of freelancing on Rails and native mobile apps, I founded and crashed a startup</a> in 2019. It was a fun, stressful and exciting experience but I'm now looking for a new opportunity. I'm an avid learner and I don't mind diving into a new tech stack. I'm comfortable with Rails, Typescript, React, ObjC/Swift, Kotlin and more recently with Rust. Infrastucture wise I usually go with Postgres, Docker and Terraform. That does not mean that I haven't played with other stacks (e.g., Python, AWS, Ansible) but we have to draw the line somewhere. I'm interested in systems and would love to dive lower in the stack. I'm also passionate about how developers and teams build software. Twitter: @fstephany</a></li> Email: francois@tamere.eu</a></li> LinkedIn</a></li> </ul> Build a modern computer course on Coursera 2017-03-08T15:00:00+00:00 I don't remember where I heard about this course but I don't regret to have enrolled in Build a Modern Computer from First Principles: From Nand to Tetris</a>. It's a 6 week course on Coursera where you build a computer from the logical NAND gate to a fully working assembler. If you don't know what a NAND gate is, don't worry, the course explains in great lengths what they are and how they work. General Impressions</h2> The course does not go into the actual physical implementation of the computer, that would probably need another 6 week course, but goes in the other direction and shows how abstractions are built on top of each other. Soon enough you end up with a full assembler that outputs binary instructions that can be executed by your CPU. I was a little bit disappointed by the way the ALU was introduced. The teachers basically gave the inner working of the ALU without any hint on how it was designed. They convinced the students that it was a simple and beautiful design but never explained how they ended up with it. Once again, I guess it is simply because the course is quit short and they only want to give an overview of the different parts. I hold a master degree in Software Engineering but this course was a joy to follow. I guess I'm biased because I knew the concepts before but it is the first time that I grasp the hardware concepts that well. Diving into hardware was a really good trip and makes me want to know more about modern computer architecture. I also made me want to dive into lower level languages (Rust, Assembler or even VHDL/Verilog). I've always been attracted by the bare metal but have never jumped into it. Now seems to be a good time. Online training</h2> This course is the first that I followed online. Coursera has the notion of "end date" which is good for actually completing the course. I registered without thinking about my activities and obligations for the 6 weeks. That's how I ended up moving (fortunately there is only 8km between the two houses), going on winter holidays with friends and continuing my Mandarin language class. While having a full time job. In retrospect, I should have waited a little bit before taking the course. I paid the 45€ as soon as I started. Not for the certificate (you can access the course for free if you don't want/need the certificate) but for the commitment. //I paid for it so I shouldn't procrastinate and finish this week's assignment.// is strong incentive to complete the course. Event if 45€ is not a huge amount of money by western standard, it puts value into the mix. One of the drawback of online training is the lack of camaraderie between students. You never see the other participants and the online forums on Coursera are basically empty. I don't know anyone in my entourage that was following the course. Having someone with who I could talk about the concepts and ideas explained in the course would have been great. Overall, it was a great experience and I'll probably enroll for Andrew Ng's course on machine learning :) Android Things 2016-12-29T15:00:00+00:00 Google announced</a> the developer preview of Android Things. You have maybe heard about Brillo</a> last year without knowing what it really was. The promise was so vague and abstract that nobody really cared (at least in my circles). With Android Things the promise is clearer. The big title on the project homepage says: The ease and power of Android If you can build an app, you can build a device </blockquote> It means that you can leverage your experience and tools to develop products. If you've already built android apps you'll be at home. You can reuse Android Studio, reuse your existing Java code and deploy this to a device with or without a screen. Good enough</h2> But was is the difference with the myriad of other products in the market? It's very easy to boot a Raspberry Pi, write some Python code and control the GPIOs to drive almost everything. The hobbyists already have all the tools they need to tinker and to build something useful. When targeting Android Things, a developer can prototype on a board and easily deploy on another one. It seems that Google has certification process for Android Thing. Switching the underlying hardware and reuse the code is already possible with other OS of course but certified boards/microprocessors could greatly improve the experience. Unless an hobbyist is a hardcore android developer there is proably not a lot of reason to pick Android Thing for your next project. Setting up the Android SDK, learning Android Studio and all the associated tools (e.g., adb</a>, logcat</a>) is not straightforward if you are doing it for the first time. It's probably faster to connect a screen, keyboard and mouse on your Pi and start coding. Updates</h2> In an industrial setting the requirements are quite different. Processes are in place and you want to leverage battle tested tools. Products can have a very long lifetime, 10-20 years is common and you might need to mass produce them. If the business is not life critical, a Raspberry Pi and your code on it is probably enough. If the product is connected to the internet, you must be much more careful about what you do and you should have a transparent update mechanism to upgrade the device remotely. Beware that this update mechanism can also be abused to compromise the deployed devices. This really is a nightmare today. In the eve of 2017, automatic and transparent updates are vital. This year, we've seen a lot of security issues from companies selling IoT devices in the fire and forget style. Consumers don't realise that their connected lightbulbs, coffee maker and fridge are actually dangerous items that can be used in huge Denial of Service attack. Manufacturers have no incentives to level up their security and update practices. Updating the OS running the devices is critical. Software companies are working hard to make this easier for developers and product manufacturers. For example, Canonical builds Ubuntu Core</a> which provices a foundation on which products can be built. This is also where Android Things can shine. It is still vaporware but Google announced that they will provide the infrastructure to remotely update deployed devices. If done well, this could be a huge win as it would remove the burden that is currently imposed to product manufacturers. It also means that a product now relies on Google's goodwill. If they shut down the service, you're screwed. Locked OS</h2> With Ubuntu Core, you have complete freedom over the OS. You can start a webserver, tune the processes that are started at startup, if you have some linux administration skills, you'll be right at home. With Android, this is another story, as a user you have much less flexibility. The OS is made for phones/tablet thus it is quite hard for apps to manipulate the system. On a phone, you don't want third party app to touch the system. When a developer builds its own system, she wants to tune it exactly to fit her need. Of course this is more dangerous but an IoT device does not have an app store. The code is loaded into it and then it should run forever (and get updates if it is connected to a network). Bare metal</h2> Now of course, all this only applies if: The device does not need connectivity to the outside world, </li> The device does not need a full blown OS. Linux (or any non-specialized OS) brings a huge overhead: you need a more expensive and more power hungry processor and it's harder to put the electronics in deep sleep mode. If realtime processing is a requirement, an OS might not be the best choice neither. </li> The device is life critical. That the software runs on top of a huge pile of software layers that the developer does not control. In life critical systems you need strong guarantees that the system handles failure. </li> </ol> In those situations a lightweight approach might be better. Something bare metal without an OS at all or with a specialized embedded one (e.g., FreeRTOS) will be more power efficient and cheaper to produce. Conclusions</h2> Android Things is trying to solve the same problem than Ubuntu Core (or other similar effort)</li> The first question when developing a product is whether or not you need full blown OS. Considering the following criteria: Cost</li> Network connectivity (and thus security)</li> Updates (both the application code and the underlying system)</li> Realtime constraints</li> Lifetime</li> </ul> </li> </ul> We will see in the following months which hardware partners Google will have and which guarantees they will give with the update mechanism. To me, Android Thing would be the killer OS if it was more moldable. There is not a lot of documentation on how to tune the system for a specific need. I guess this will come with time and experience. Exciting times. Android Google Study Jams Brussels Episode 2 2015-03-10T23:00:00+00:00 We are now at week 6 of the google study jam in Brussels. Things have been smooth so far. We are a core group of attendees with different backgrounds and goals, which is always nice. This week's lesson was about Content Provider</a> and the URI concepts. Most of the questions were about the utility of this way of doing and we talked quite a lot about the different strategies to load data into an application. Here are the links about the tools and libraries people have mentioned: greenDAO</a>, an ORM which adds a build step into the build process: you write a java program that runs on your computer and that generates your model classes with all the machinery to let you query them.</li> Sprinkles</a>, a lightweight library around SQLite. It provides a mapping with your model object throughout Java annotations. It's quite simple to setup and does not hide the SQL complexity: you write your query by hand and it provides the object mapping. This is the one I currently use for my projects.</li> sqlite-analyzer</a>, written by Novoda, it can generates Java code from sqlite migration/databases. Pretty handy.</li> sqlite-provider</a>, simplifies the use of sqlite with ContentProvider.</li> android-content-provider-generator</a>, mentioned by an attendee (hi Maxime</a>!), this library generates a ContentProvider from a JSON file that describes your model. </li> </ul> All in all, the most important lesson is that people should use what they're comfortable with. Choosing a persistence strategy is something that you should think about. Using external libraries that are far from the android way of doing also conveys a certain risk (e.g., library maintenance). We also had a question about how to do animations and how to read/manipulate SVG objects. This is also a large topic but here are a few pointers: Romain Guy's blog post</a> about path tracing and SVG. The companion app</a> is something that you want to clone.</li> Android SVG</a> a library to manipulate SVG</li> Some blog post about animating the Toolbar while scrolling: Arnaud Camus</a> and Michał Z</a>. Both have Github example projects.</li> A very good presentation by Daniel Lew</a> about all the different options you have to do animations on android. Some stuff are dated but it's a good start.</li> A blog post</a> on the official Android developer blog about ViewPropertyAnimator.</li> There's an app that aggregates a lot of open source library and most of them have demos. It's quite nice if you need to find something: Libraries for Developers</a>.</li> </ul> Once again, if you're interested and want to participate, join the Google Developer Group Brussels</a> on Meetup! Android Google Study Jams Brussels 2015-02-25T11:00:00+00:00 The Google Developer Study Jams Android Fundamentals</a> is a worldwide study group organised by Google and Udacity. The principle is quite simple: people follows an online course on Udacity to become Android developers. Events are locally organized weekly so participants can share their problems, ideas and solutions. The official website describes it perfectly: Study Jams are an opportunity for students to receive free, in-person guidance and tutoring on the Udacity course in a fun classroom environment. Study Jam sessions are designed around the Udacity course structure, with a weekly session following each lesson (6 lessons), plus two additional weeks for completing and sharing course final projects. Students are expected to come to the Study Jam sessions having completed that week’s Udacity lesson online, so that the Study Jam time may be used to review key concepts, address questions, and work on individual projects. The live community atmosphere and tutoring is designed to help students achieve deeper learning around the concepts taught in the course. </blockquote> The Google Developer Group of Brussels</a> is organising the local event in Belgium in the beautiful working space Co.Station</a>, next to the central station. Friedger Müffke</a> and I are the two tutors for the Brussels local group. We try to expand the content of the online course with some of our experiences. We also try to give the student a feeling of the Android ecosystem. The Android fondamental course does not use any external libraries. Even for HTTP calls. Instead they ask the students to copy/paste a huge gist containing the code doing the call. I thought that it would have been nice to show the students how to include an external library. We started to follow that path and we talked quite a lot about libraries that I find useful. Here are some of them: OkHTTP</a>, HTTP calls should be easy.</li> GSON</a>, JSON manipulation.</li> Retrofit</a>, Ideal if you want to interact with a REST+JSON webservice. Beware that it can feel a little bit magic, it's hard to know what's going on. It relies on OkHTTP and GSON to do its job.</li> EventBus</a>, an EventBus for your application. It lets you send event throughout your application. *Otto</a>, basically the same as EventBus. Try both and keep the one you prefer.</li> Timber</a>, small librarie that makes it easier to deal with logs. </li> </ul> You can find all those library in the jcenter maven repository</a>. Many of those libraries are edited by Square. Check their open source listing</a> for more goodness. Another small tool that we covered (but that I haven't tested in real life yet) is Retrolambda</a>. You integrate it into your build chain and it lets you write lambda expressions with java 7. Nobody knows when (or even if) Java 8 will be available on android, so this tool can come handy if you really want to use those lambdas. We also mentioned Genymotion</a>, a fast android emulator based on VirtualBox. Someone has a question about Context</code> last week. This article</a> is quite good to grasp the differences between the different available contexts. Last but not least, we talked about Android Weekly</a>, a very nice newsletter that collects all the news from the Android ecosytem. It is a great way to discover new libraries and tools. Thanks a lot to Anne Collet</a> from Le Wagon Brussels</a> to host us in Co.Station. If you're interested and want to participate, join the Google Developer Group Brussels</a> on Meetup! Dependency injection with Dagger 2015-01-13T16:48:00+00:00 Dependency injection</a> (or DI) is quite a big topic in object oriented design. It can be quite hard to grasp for junior developers but it is a pattern that should be in your toolbox. This small blog post will briefly show you how to use Dagger</a>, a common DI framework in the Android world. Android Example</h2> Jake Wharton's u2020</a> is an Android app showcasing the use of dependency injection using Dagger. The app is full of great tips but taken together, they can be a bit overwhelming if you just want to learn the framework. The injection depends on the variant of the app: the debug</code> version have a completely different layout that includes a debug drawer. It is a great learning app but you probably don't want to deal with all that complexity when you just want to learn how Dagger works. Our app: Inject an Webview url at runtime</h2> To illustrate the DI, we will change the url displayed by a webview at runtime. Change url by endpoint and webview by API and you'll have a very common scheme in Mobile apps. This can be useful if you want to switch between your testing and staging servers to test that everything is working. In this post, we'll see how we can dynamically change the endpoint our app is talking to. Beware that it could become dangerous in a real application: dynamically changing the endpoint at runtime is not a good idea if you have a session on the server or if you use a local database to synchronise data with the backend. You can easily meangle all your data and send inconsistent requests to the server. Our app</a> will be very simple: a webview and radio buttons. The webview will display Yahoo or Bing according to the currently selected radio button. Annotations</h2> This app shows three very simple annotations of Dagger: @Inject</code>, @Provides</code> and @Module</code>. @Inject</code> (on a field)</h3> This annotation shows that you want to inject a value in this field. We will see later when values are injected. @Provides</code> (on a method)</h3> @Provides</code> shows that the annotated method can provide a value. Provider methods are part of a Module. @Module</code> (on a class)</h3> A module is the entry point of the injection. We will build our object graph with a Set of modules. We then inject objects that have injectable fields into this object graph to get them populated. Code</h2> The app has two modules, BingEndPointModule</code> and YahooEndPointModule</code>. Those are injected at runtime when you choose Bing and Yahoo in the UI. @Module(injects = { MainActivity.class }) public class BingEndpointModule { @Provides Endpoint provideEndpoint() { return new Endpoint("http://bing.com/"); } } </code></pre> In the @Module</code> annotation, you can notice that you have to provide where this module will be injected. Dagger verify at compile time that you haven't messed up. In the main activity, we wrote a simple method to switch: private void updateModule(Object module) { objectGraph = ObjectGraph.create(module); objectGraph.inject(this); refreshWebview(); } </code></pre> Which is called when we change the selection of the RadioGroup: private void selectBing() { updateModule(new BingEndpointModule()); } </code></pre> As you see, there is nothing really fancy in this code. I wouldn't use Dagger for such a simple case in practice but keeping it small helps to identify the key parts of Dagger. You can get the whole source code on the Github repository</a>. Closing</h2> That was short. Once again, you should clone u2020</a> and study its source code. It shows quite a lot in a condensed app. Pharo packages to know 2014-06-02T00:08:00+00:00 Starting to work with Pharo Smalltalk these days is quite a non trivial process. Non-smalltalkers are already lost with the language and the environment. On top of that, they must learn tools and library names that are quite specific to Smalltalk or Pharo. Here's my short list of project name to know: Morphic: The GUI layer of Pharo. It is not really</li> Spec</a>: A framework to describe user interfaces. It powers quite a few tools in the Pharo environment. At the moment, it uses Morphic as the backend but it should eventually be backend-agnostic.</li> Nautilus: The code browser. It's the primary tool to interact with your code.</li> Zinc</a>: an HTTP client and server library integrated into Pharo</li> Monticello: A source control (think Git but specialized for Smalltalk packages) dedicated to Smalltalk. It outputs .mcz</code> packages that contain the whole source code for a given version. </li> Gofer: A tool helping you to grab Monticello packages. It can be used to script the loading of Monticello Package</li> Metacello: A tool to express the dependencies for your project. Think Bundler, Maven or Pip for Smalltalk. You usually grab the MetacelloConfiguration of a package with Gofer and then ask the configuration to load the project.</li> Versionner: A Graphical tool to help you create your Metacello configurations.</li> Athens: A new vectorial backend for Pharo. It will eventually replace the current rendering engine. It is based on Cairo.</li> NativeBoost: A library to call C libraries from Pharo. Other projects exist (e.g., FFI, Mars) but NativeBoost (NB) is probably the way to go for new projects.</li> Filetree: Filetree lets you write Monticello packages into the regular filesystem. If you want to use git, this is the way to go. There are efforts to use git natively with the tools available in the image (e.g., gitfiletree).</li> </ul> There a many more but those are probably the core packages that a newcomer will hear about when (s)he starts to play with Pharo. I've linked some of the projects to their homepage but all the others should be covered by Deep into Pharo</a> and Pharo For the Entreprise</a>. Ping me on Twitter</a> if I forgot an important package that does not have a meaningful name. iOS legacy code 2013-10-26T16:40:00+00:00 Confession: I love dealing with legacy code. I love to curse when reading source code. I love to refactor all those defects that make my eyes bleed. In this post, I describe some smells that I often see when taking over or assessing iOS apps. Conclusions</h2> Code duplication. Copy/Pasting a snippet of code from time to time is OK. Copying the same 60 lines in almost all your ViewController</code> is definitely bad.</li> Naming convention. The use of singular and plural should not be incidental. It brings clarity to your code. Do not start methods name with a capital letter. Use meaningful variable names. Objective-C is verbose because people express everything in the naming. Don't break that.</li> Indentation and whitespace. This is at a microscopic level but you should have a consistent coding style. Always pout your opening brackets at the same place, separate your methods definition by one empty line, etc. Those are simple rules but helps to read your source code.</li> Magic constants. The return codes are obscure. If you really want to identify errors with error codes, at least create constants so the reader knows what you mean by Error 42. NSError</code> is made for this, do not go with your own solution that works half of the time.</li> Data Modeling. Use your custom ORM only in specific cases. Apple provides a good framework that everybody knows and uses: CoreData. It is a huge and complex piece of software but it can handle almost every situation and is battle tested.</li> Code clarity. You should always express the same concept with the same code structure. For example a screen showing a note should have a variable called currentNote</code>representing the note currently displayed. And not an array containing all the notes with another variable telling the index of the current note in the array. It confuses the reader. If you go that way, you must explain the reason in concise comments.</li> Properties vs Instance variable. Use one or the other but do not mix them without any reasons. As a side notes, accessors/mutators are generated for you. Do not replicate your Java habits in here.</li> Objective-C. Obj-C has improved over time to make it easier to read, easier to write. The new features tend to make it easier to remove the boilerplate of the code. (@</code> notation, auto-synthesize properties, etc). Know the language you are using.</li> Custom UI. Two simple rules : Use the appearance proxies</code> if you want to the same component all over the app.</li> Do not use magic constants for sizes and frames. If Apple changes the screen for the iPhone 6, you'll get screwed.</li> </ul> </li> Certificate. Always use the signing certificate of your clients. If they don't know how to create it, generate it with them, not for them. The certificates control everything for publishing apps. If your clients are not happy with you, you should let them go.</li> Arc. Use arc. You do not want to manage your memory by hand. The cases where the compiler gets it wrong are incredibly rare.</li> </ul> Post-mortem</h2> Those notes are quite broken and do not follow any logic, I've copy-pasted some snippets from some projects I've helped to assess. I suck at editing, do not expect this blog post to be a complete, clean and accurate report of defects in iOS Code. It covers stuff at the code snippet level; there is more to tell about architecture of apps but the subject is too broad for this rant. UIViewController & UI Tuning</h3> Almost every single ViewController starts with the following: - (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]; if (self) { // Custom initialization } return self; } -(void)viewWillAppear:(BOOL)animated{ [super viewWillAppear:animated]; [self loadApparence]; } </code></pre> What's wrong with this: The first method is useless. Why keep the cruft if you don't need it.</li> Whitespace boy. One empty line between the methods is all I ask.</li> </ul> Ok. Let's have a look at loadApparence</code>. I'm gonna split it to make it easier to read. - (void) loadApparence { [[self navigationController] setNavigationBarHidden:NO]; [self.navigationController.navigationBar setTintColor:[UIColor grayColor]]; if ([self.navigationController.navigationBar respondsToSelector:@selector(setBackgroundImage:forBarMetrics:)]) { [self.navigationController.navigationBar setBackgroundImage:[UIImage imageNamed:@"bg_Navigation_Header.png"] forBarMetrics:UIBarMetricsDefault]; } if ([self.navigationController.navigationBar respondsToSelector:@selector(setTitleTextAttributes:)]) { [self.navigationController.navigationBar setTitleTextAttributes: [NSDictionary dictionaryWithObjectsAndKeys:[UIColor navigationTitleTextColor], UITextAttributeTextColor, [UIColor colorWithRed:0.0 green:0.0 blue:0.0 alpha:0.0], UITextAttributeTextShadowColor, [NSValue valueWithUIOffset:UIOffsetMake(0, 0)], UITextAttributeTextShadowOffset, [UIFont fontWithName:@"Klavika-Medium" size:22.0], UITextAttributeFont, nil]]; } … </code></pre> Mmmm. At first sight: - (void) loadApparence</code>. French developer spotted.</li> I know that it's sometimes hard in Objective-C/Cocoa but the 80 caracter wide rules should be enforced when possible. Not everyone codes fullscreen on a 27'' monitor.</li> I always worry when I see respondsToSelector:</code>. It usually means that the developer has missed some object-oriented polymorphism. In this case it looks like he is checking that the navigation bar has all the capabilities it is supposed to have. Maybe because of API changes in the UINavigationController? A comment would have been welcome.</li> Changing the navigation bar background. I bet this happens everywhere in the project. BINGO, after a quick search, the line [self.navigationController.navigationBar setBackgroundImage:[UIImage imageNamed:@"bg_Navigation_Header.png"] forBarMetrics:UIBarMetricsDefault];</code> appears 22 times in the project. This code has been copy/pasted everywhere. Why not use the appearance proxy of externalise this code if you compile under iOS 5 (is there anyone still using iOS < 5 in 2013?)</li> dictionaryWithObjectsAndKeys:</code>? Really? The @</code> notation should be used everywhere.</li> </ul> UIButton *buttonSave = [UIButton buttonWithType:UIButtonTypeCustom]; [buttonSave setBackgroundImage:[UIImage imageNamed:@"btn_blue_normal.png"] forState:UIControlStateNormal]; [buttonSave setBackgroundImage:[UIImage imageNamed:@"btn_blue_pressed.png"] forState:UIControlEventTouchUpInside]; [buttonSave setBackgroundImage:[UIImage imageNamed:@"btn_blue_pressed.png"] forState:UIControlStateHighlighted]; [buttonSave.titleLabel setFont:[UIFont fontWithName: @"Custom-Medium" size:16]]; [buttonSave setFrame:CGRectMake(0, 0, 44, 31)]; [buttonSave setTitleEdgeInsets:UIEdgeInsetsMake(8, 0, 0, 0)]; [buttonSave setHighlighted:NO]; [buttonSave addTarget:self action:@selector(save:) forControlEvents:UIControlEventTouchUpInside]; [buttonSave setTitle:myFunkyLocalizeFunction(@"Save") forState:UIControlStateNormal]; UIBarButtonItem *saveButton = [[[UIBarButtonItem alloc] initWithCustomView:buttonSave] autorelease]; self.navigationItem.rightBarButtonItem = saveButton; UIButton *buttonCancel = [UIButton buttonWithType:UIButtonTypeCustom]; [buttonCancel setBackgroundImage:[UIImage imageNamed:@"btn_grey_normal.png"] forState:UIControlStateNormal]; [buttonCancel setBackgroundImage:[UIImage imageNamed:@"btn_grey_pressed.png"] forState:UIControlEventTouchUpInside]; [buttonCancel setBackgroundImage:[UIImage imageNamed:@"btn_grey_pressed.png"] forState:UIControlStateHighlighted]; [buttonCancel.titleLabel setFont:[UIFont fontWithName: @"Custom-Medium" size:16]]; [buttonCancel setFrame:CGRectMake(0, 0, 60, 31)]; [buttonCancel setTitleEdgeInsets:UIEdgeInsetsMake(8, 0, 0, 0)]; [buttonCancel setHighlighted:NO]; [buttonCancel addTarget:self action:@selector(cancel:) forControlEvents:UIControlEventTouchUpInside]; [buttonCancel setTitle:myFunkyLocalizeFunction(@"Cancel") forState:UIControlStateNormal]; [buttonCancel setTitleColor:[UIColor colorWithRed:0.5 green:0.52 blue:0.57 alpha:1] forState:UIControlStateNormal] ; UIBarButtonItem *cancelBtBar = [[[UIBarButtonItem alloc] initWithCustomView:buttonCancel]autorelease]; </code></pre> This snippet has been copy/pasted everywhere the save and cancel button are neded.</li> [UIFont fontWithName: @"Custom-Medium" size:16]]</code> is everywhere.</li> The experienced eye will have noticed that [buttonSave setBackgroundImage:[UIImage imageNamed:@"btn_blue_pressed.png"] forState:UIControlEventTouchUpInside];</code> will generate the warning "Implicit conversion from enumeration type 'enum UIControlEvents' to different enumeration type 'UIControlState' (aka 'enum UIControlState')".</li> </ul> Return codes</h3> if(([description isEqualToString:@"DELETE_NOTE"])&&([targetType isEqualToString:@"FOLDER"])) { XXXFolder *folder = [[XXXFolder alloc] initWithDictionnary:[adic objectForKey:@"target"]]; XXXNote *note = [[XXXNote alloc] initWithDictionnary:[[adic objectForKey:@"target"] objectForKey:@"note"]]; if((folder)&&(note)) { self.objects = [[[NSDictionary alloc] initWithObjects:@[folder, note] forKeys:@[@"folder", @"note"]] autorelease]; return 20; } } </code></pre> Does anybody knows what the return code 20 means? I do not have a clue. The other parts of the if</code> (and there are 13 consecutive if</code> clauses) return a different code. That line mixing two syntax is particularly cool. The array is declared the new way while the dictionary is declared the old school way (it was a one liner, I idented it to make it more readable): self.objects = [[[NSDictionary alloc] initWithObjects:@[folder, note] forKeys:@[@"folder", @"note"]] autorelease];` </code></pre> while they could have used: self.objects = @{ @"folder":folder, @"note":note }; </code></pre> or even: self.objects = NSDictionaryOfVariableBindings(folder, note); </code></pre> Mixing Properties and instance variables</h3> @interface XXXNoteDetailViewController : UIViewController <UITextFieldDelegate, UITextViewDelegate> { SoundEffect *player; IBOutlet UIButton *addTaskButton; IBOutlet UIButton *connectToFolderButton; IBOutlet UIButton *shareNoteButton; IBOutlet UIButton *editTaskButton; IBOutlet UIButton *deleteNoteButton; IBOutlet UIView *controlBarView; IBOutlet UIButton *commentsButton; } @property (retain, nonatomic) IBOutlet UIImageView *photoImageView; // And 21 more properties for UI elements. </code></pre> Pick one approach and stick with it. Don't mix them without reason. Meta programming</h3> - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view from its nib. [self performSelector:@selector(loadNote)]; } </code></pre> I'm still wondering why the performSelector:</code> is there. Isn't - (void)viewDidLoad { [super viewDidLoad]; [self loadNote]; } </code></pre> easier to read? Properties</h3> XXXNoteDetailViewController</code> displays a note. Why does it need to keep a whole notes</code> array and a property called ind</code> to hold the index of the note to display? notes</code> is never used. Except to retrieve the note to display. Many methods start with: Note *note = [notes objectAtIndex:ind];</code>. Oh oh no, it's used when the user deletes the currently displayed note: [notes removeObjectAtIndex:ind]; if ([notes count] > 0) { ind--; if (ind > 0 && ind < [notes count]) { [notes objectAtIndex:ind]; } else { ind = 0; [notes objectAtIndex:0]; } } else { [[self navigationController] popViewControllerAnimated:YES]; } </code></pre> Ouch. Java-ite</h3> @property (nonatomic, retain, setter = setContent:, getter = getContent) NSString *content; </code></pre> Accessors are generated for properties, do not try to make it look like Java. Ifs</h3> if(self.currentNote) { if (![[NSFileManager defaultManager] fileExistsAtPath:fullPath]) NSLog(@"fichier inexistant : %@", fullPath); // [[SoundManager getInstance] playSoundFromPath:fullPath]; if([player loadContentsOfFile:fullPath]) { NSLog(@"playing %@", fullPath); [player play]; } else{ NSLog(@"impossible de lire le fichier : %@", fullPath); } } </code></pre> This if clause probably violates all the good practices you've ever learned for conditions. Whitespace</h3> Method declaration identation is quite funky (white space preserved): -(NSDictionary *)dicValue; -(id)initWithContentArray:(NSMutableArray*)acontentArray; - (id)initWithDictionnary:(NSDictionary*)adic; -(void) addEmails:(NSString *)emails; -(void)save; - (void) setShareEmailsWithArray:(NSArray *)shareEmails; - (NSArray *)getShareEmailsArray; -(BOOL) isOwner; </code></pre> One empty line between method declaration should be the norm. Managing database</h3> [dataBaseManager registerAndGetQueryResult:@"INSERT OR REPLACE INTO tasks (id, description, date_creation, complete, date_complete, due_date, alarm_date, id_note, updatedate, tosend, ownerid, shareemails) VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, 0, ?,?)" withParams:@"%@%@%@%d%@%@%@%@%@%@", task.identifier, task.description, task.dateCreation, task.isComplete, task.dateComplete, task.dueDate, task.alarmDate, task.idNote, task.updateDate, task.ownerId, task.shareEmails]; </code></pre> All the database interaction is made in pure SQL. A custom in-house framework is used to manage all the queries/inserts/updates. Why not go with CoreData ? It's the standard on iOS and contains everything a developer need. It's a bit complex at first but it can save a lot of time afterwards. Magic constants</h3> - (void) showItemWithItem:(XXXTimelineItem *)timelineItem { switch (timelineItem.type) { case 1: case 18: case 19: [self showTodo]; break; case 3: case 4: case 5: case 6: case 7: case 10: case 15: case 21: [self showFolderWithItem:timelineItem]; break; case 2: case 8: case 9: case 11: case 12: case 13: case 14: case 16: case 17: [self showNoteWithItem:timelineItem]; break; default: break; } } </code></pre> String typing</h3> if ([self.currentNote.getType isEqualToString:@"TEXT"]) {…} else if([self.currentNote.getType isEqualToString:@"PHOTO"]) {…} else if([self.currentNote.getType isEqualToString:@"AUDIO"]) {…} </code></pre> Ouch. Libraries</h3> CocoaPods is the way to go to manage libraries. The projects has Stig Brautaset's JSON tools copied into the project. The AWSiOsSDK also uses this json parser. Boum. Gradle Build Variants for your android project 2013-10-05T22:43:00+00:00 When developing an app, you usually have many slightly different versions of this app. The most common example is probably the backend you want to use: production or staging. You usually define the base URLs with the other constants of the app. Switching from one environment to the other is done by (un)commenting the right lines: public static String BASE_URL = "http://staging.tamere.be" //public static String BASE_URL = "http://production.tamere.be" </code></pre> The process is manual, boring and error prone but hey, changing one line is not that bad, is it? Then you add more and more features that depends on the environment. You maybe want a different icon and then different input validation rules and then ... That's where your build tool can help. Let's see how we can automate the process of generating different APKs for different environment with Gradle. Build variants</h2> Gradle has the concepts of Build Types and Build Flavors. When combining the two, you get a Build Variant. There two default build types: release and debug. We won't change them in our example but we will create two new flavors: production and staging. As a result, we'll have four different variants: ProductionDebug</li> ProductionRelease</li> StagingDebug</li> StagingRelease</li> </ul> Sample project</h2> The project is pretty simple but shows how you can define for each build variant: an app name</li> an icon</li> constants (in our case a BASE_URL</code> variable)</li> </ul> You can download the project on Github</a>. Here are two screenshots of the generated apps. Nothing really fancy: build.gradle file</h2> buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.5.+' } } apply plugin: 'android' repositories { mavenCentral() } android { compileSdkVersion 18 buildToolsVersion "18.0.1" defaultConfig { minSdkVersion 15 targetSdkVersion 18 } productFlavors { production { packageName "be.tamere.gradlebuildtypesexample" } staging { packageName "be.tamere.gradlebuildtypesexample.staging" } } } dependencies { compile 'com.android.support:appcompat-v7:18.0.0' } </code></pre> The definition of the flavors is super simple, all the magic will happen in their folders. File structure</h2> In the src</code> folder, we've created two directories whose names must match the flavors. We will define all the flavor-specific values. Only specific values are necessary. The staging version defines new icons while both flavors defines a Constants.java</code>. The app name is defined in the string.xml</code> files. ├── main │ ├── AndroidManifest.xml │ ├── ic_launcher-web.png │ ├── java │ │ └── be │ │ └── tamere │ │ └── gradlebuildtypesexample │ │ └── MainActivity.java │ └── res │ ├── drawable-hdpi │ │ └── ic_launcher.png │ ├── drawable-mdpi │ │ └── ic_launcher.png │ ├── drawable-xhdpi │ │ └── ic_launcher.png │ ├── drawable-xxhdpi │ │ └── ic_launcher.png │ ├── layout │ │ └── activity_main.xml │ ├── menu │ │ └── main.xml │ ├── values │ │ ├── dimens.xml │ │ ├── strings.xml │ │ └── styles.xml │ ├── values-v11 │ │ └── styles.xml │ └── values-v14 │ └── styles.xml ├── production │ └── java │ └── be │ └── tamere │ └── gradlebuildtypesexample │ └── Constants.java └── staging ├── java │ └── be │ └── tamere │ └── gradlebuildtypesexample │ └── Constants.java └── res ├── drawable-hdpi │ └── ic_launcher.png ├── drawable-mdpi │ └── ic_launcher.png ├── drawable-xhdpi │ └── ic_launcher.png ├── drawable-xxhdpi │ └── ic_launcher.png └── values └── string.xml </code></pre> Android Studio</h2> You can switch between the two flavors in the Build variants</code> tab of the IDE. Android Studio has some trouble identifying the resources for a non-active flavors. We are using the production</code> flavor, Studio does not understand that the staging</code> folder contains source code. Don't worry, it's normal, it will catch up when you switch to the staging variant. Launch the app with the different flavors to see the result. The app drawer shows the two icons: References</h2> http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors</a></li> Xav's answer on this Stack overflow topic</a> is particularly helpful.</li> </ul> UILocalNotification alertBody 2013-06-06T12:44:00+00:00 Once again, this post is more a reminder to self</code> than a real blog post but I've been bitten by that one. Always set the alertBody</code> of a UILocalNotification</code>. If you don't, nothing will appear when the application is on the background. The documentation</a> mentions it but it's pretty easy to miss the remark: Assign a string or, preferably, a localized-string key (using NSLocalizedString) as the value of the message. If the value of this property is non-nil, an alert is displayed. The default value is nil (no alert). </blockquote> Creating a local notification without any content is probably not common but it can happen while developing with the I will add text later mindset. Scroll UITableView to currently selected UITextField 2013-05-20T23:30:00+00:00 Situation</h2> I have a UITableView</code>. Each cell of the table view has a UITextField</code> in its contentView</code>. The table view is actually a giant form. In iOS when a tableView has cells containing textfield, it is supposed to scroll when a textfield becomes the first responder so focused textfield is visible when the user edits its content. It wasn't the case for me. Solution</h2> Do not forget the [textField resignFirstResponder]</code> when passing the isFirstResponder</code> to the next textfield. Otherwise the tableView won't scroll to the new first responder when editing. {% highlight objective-c %} (BOOL)textFieldShouldReturn:(UITextField )textField { NSInteger nextTag = textField.tag + 1; UIView nextResponder = [self.view viewWithTag:nextTag]; [textField resignFirstResponder]; if (nextResponder) { [nextResponder becomeFirstResponder]; } return YES; } </li> </ul> {% endhighlight %} Et voilà, the tableView will scroll as you expect. Pharo Sprint in Lille 2012-11-04T12:30:00+00:00 The RMoD</a> team held a sprint in their new office in Inria Lille</a> last Friday. It was the occasion to meet in real life and to smash some bugs. Camillo</a> showed us how to use the bug tracker and how to submit a patch for integration. Overall the process is much easier than I expected. I paired with Mariano for a couple of hours. We started something too big for the time we had so we warmed up on an annoying bug</a> we found while fixing what we initially planned to do. We then tried to clean OSProcess to load it in Pharo 2.0</a>. Once again, we probably picked something too big and I had to leave early so we didn't finish but we made some progress (I hope ;)) </div> (pictures by Marcus Denker</a>) In total, 18 bugs were solved (only two of them are not integrated yet), 8 others were fixed but need a second review and around 10 were closed for other reasons. All of this in a happy english/french/spanish speaking atmosphere. I had never paired with someone in Smalltalk before. This kind of experience reminds me why I like programming. Thanks guys! Migrating from MS Works to LibreOffice - batch processing 2012-11-03T03:48:00+00:00 A forensic doctor</a> came to me with a very specific problem; he was using Microsoft Works</a> for years. He upgraded version after version without too much hassle but when Microsoft discontinued it, this doctor was worried about the long-term preservation of his data (all documents must be kept available for 30 years). He grew up tired of Windows and to make things worse, he bought an iPhone last year. It was then decided that his next laptop would be a Mac. Executing Works on a Mac is not an option in the long term but is tolerate during the migration, Parallels Desktop</a> has a great Coherence mode where Windows application behave like Mac ones. Kill all the compiling! 2012-09-28T12:44:00+00:00 Two cool projects, one in Ruby/Javascript, the other in Pharo Smalltalk. They both try to get rid of unnecessary compilation of source code. TurboLinks</h2> TurboLinks</a> speeds up Rails app. Basically, when you click on a link of your application, `body` and `title` are replaced. The browser does not load a whole new page. This avoids the recompilation of all the javascript and CSS by the browser. TurboLinks takes care of the history by using pushState</a>. It falls back to the regular behaviour if the browser does not support `pushState`. The speedup is quite visible, especially if you have a lot of Javascript and are on a mobile browser. Tanker</h2> Managing packages in Pharo/Squeak is quite a pain. Metacello helps but loading a project and all its dependencies takes a loooooong time. Try to load Seaside</a>, Magritte</a>, and CloudFork</a>, you’ll understand what I mean. The reason is simple: a Monticello package contains the plain sources. When loading it, Pharo has to compile all the sources. Tanker</a> uses the Fuel serialiser</a> to load your code. It serialises the compiled methods and can restore them in another image without the need for recompiling. Loading seaside now takes around 20 seconds (it could take ~10-15 minutes before). edit: Mariano</a>’s comment clarifies the loading speed of Tanker versus Monticello loading. I went a bit too fast to my conclusion ;) Seaside wrapper for Filepicker.io 2012-09-26T18:17:00+00:00 To me, uploading has always been the messier part in web application. Some will argue that the fun starts when you want to do ajax uploading. Filepicker.io</a> solves the problem quite elegantly. Mega bonus point, they integrate nicely with Dropbox, Gmail, Google drive, Facebook and others. So your user can pick a file on her hard drive, dropbox or even take a picture with the webcam. The integration</a> is pretty straightforward but to make things even easier I’ve started a small wrapper for Seaside. You can find it on Squeaksource 3</a>. Right now, it only performs the basic but I’ll add features when I need them. html form with: [ html fileInput on: #uploadedFileUrl of: self; apiKey: 'yourApiKey'; beDragNDrop. html break. html submitButton with: 'Send the form.' ]. </code></pre> When the user selects a file and sends the form, the instance variable `uploadedFileUrl` will contain the url of the uploaded file. You can then grab it and do whatever you want with the file. You can grab the `Filepickerio-Test` package in the repo, it contains a sample application showing how to use it. I’ve only tested on Pharo 1.4 Summer edition and Seaside 3.0.7. The code is quite simple and should work everywhere though… Oh, the repo is global read/write and the code is MIT ;) Deploying Pharo Application 2012-07-04T13:59:10+00:00 People sometimes asks me how to deploy Smalltalk applications. I’ve only worked with Squeak and Pharo with server side application so I only covers those two dialects in that context. It all start easy. Basically, you write a script that you can use with a process monitoring daemon (I use monit</a> but any will do the trick). This daemon will start/restart/stop your application with your script. So far, I never had any problems with this system. Now how does your startup script should look like? Here is an overview of the different possibilities. Please comment if you use an other strategy. Create an image locally and upload it</h2> That’s the most basic scenario. You create your image locally, load everything you need and then upload it to your server with S/FTP. Slow and painful, you want to avoid this process. Load everything all the time</h2> Your script takes a fresh image, load your Metacello configuration and hopla, it’s ready to go. You never save the image. It is used as a runtime and there’s no need to save it. I love this approach for its simplicity. It is also pretty clean as you never rot your image and everything is wiped out when you restart. Acutally it looks like a regular web application in, say, Ruby. Ruby loads your code and the dependent gems and run your code. Unfortunately it has a huge drawback. Metacello will look at all your dependencies and load the versions you defined. You need to rely on other people configurations and hope that their repo are still reachable. Have you ever encoutered a broken Metacello configuration? How many time squeaksource</a> has been down lately? The recent outage with Lukas Renggli repository (which contained many open source projects) also shows the limitation of this model. Another issue is the time it takes to load packages with Monticello. Most of my projects depends on Seaside, Magritte, Cloudfork and others. Loading all those can take up to 20 minutes. It means that you need to wait every time your application restarts. Annoying. There’s a GSOC project going on that will solve this problem by providing binary packages (so you don’t need to recompile everything you load). It’s not there yet and you need a binary version of all the project you depend on. Prepare a base image with CI server</h2> For this one, you load your project and its dependencies once in an image. You save it. Then you tell your process monitoring daemon to just launch it. Once it started, you never save it. If it crashes, you simply restart the prepared image. With this approach, you need to generate the base image. You can do it manually but a continuous integration server can help a lot. You can create a hook that regenerate the base image when you update your Metacello configuration for example. This scenario removes the problem of loading time. When your application crashes, it can restart instantly, you don’t need to reload everything. But you need a CI server to automate the construction of the image. Conclusion</h2> The first approach is clearly not optimal. It works for very small project but does not scale at all. Ideally, your deployment process should be as smooth as possible. A Heroku</a> like deployment would be super cool to have but so far Smalltalkers all have their own scripts, there are no standardized solutions. Note that those strategies show their limitation only at the first launch or when they restart. In many situations, you can update your code when it’s running, without restarting the image. Smalltalker, what is your deployment process? Misc stuff about Voyage and MongoDB 2012-05-28T17:01:00+00:00 Esteban</a> replied to my first post</a></a> about Voyage</a>. Unfortunately, my blog provider messed up when formatting the comment. Here’s a summary of his remarks: Magritte</h2> Magritte is not necessary for the basic scenarios. Voyage is smart enough to infer the types of your instance variables and can serialize them. You don’t need to describe everything like you would do when building an UI with Magritte. The Magritte descriptions are only needed when you want to override the defaults of want to have a one-to-many relationships. In the future, it will be able to infer the to-many relations automatically but at the moment you still have to tell voyage how to deal with them. ^VOMongoToManyDescription new attributeName: 'myInstVar'; "Acts on this inst var" kindCollection: Set; "Set instead an OrderedCollection" beLazy; "I want that references to be retrieved lazily" yourself. </code></pre> Browse VOMongoRelationDescription</code> and its subclasses to see what is possible. Embedded documents</h2> As we've seen previously</a>, it is pretty easy to map a relation. In our example, we declared both MQSpaceship</code> and MQPilot</code> as persistent by implementing isPersistent</code> on the class side. This isPersistent</code> method has an unfortunate name. It actually means that a collection with the name of the class will be created in the database. If we hadn’t declared MQPilot</code> persistent, it would have been completely embedded in the spaceship. Ignore instance variable</h2> Sometimes you do not want to serialize all your instance variables. In such cases, add a VOMongoTransientDescription</code> like this: mongoTransientDescription ^VOMongoTransientDescription new attributeName: ‘puppies’; yourself. </code></pre> Now, the puppies</code> instance variable will be ignored by the serializer and won’t be stored in Mongo. That’s all for today. Once again, huge thanks to Esteban for this super nice library! Embedded Document with Voyage in MongoDB 2012-05-24T19:15:00+00:00 In my previous post</a>. I was wondering how Voyage would handle embedded documents. The answer is pretty simple. Let’s see with an example ( MQ stands for for Mars Quest): Object subclass: #MQSpaceship instanceVariableNames: 'pilot name' classVariableNames: '' poolDictionaries: '' category: 'MarsQuest' Object subclass: #MQPilot instanceVariableNames: 'name' classVariableNames: '' poolDictionaries: '' category: 'MarsQuest' MQSpaceship class>>isPersistent ^true MQPilot class>>isPersistent ^true </code></pre> Generate the accessors for the instance variables (yeah, name</code> is super annoying). And execute the following: (MQSpaceship new name: 'Batmobile'; pilot: (MQPilot new name: 'Batman')) save. </code></pre> Voyage will generate two collection in your database: spaceship</code> and pilot</code>. The spaceship record we’ve just created is: { "_id": ObjectId("f65bd8790000000000000000"), "#instanceOf": "MQSpaceship", "name": "Batmobile", "pilot": { "#collection": "pilot", "#instanceOf": "MQPilot", "__id": ObjectId("85f61e070000000000000000") } } </code></pre> And the pilot record: { "_id": ObjectId("85f61e070000000000000000"), "#instanceOf": "MQPilot", "name": "Batman" } </code></pre> So we didn’t completely embed the Pilot into the Spaceship document but have defined a relation. This is something you would or wouldn’t want depending of your data and what kind of query you need to perform on them (this talk</a> explains modeling choices in MongoDB). When you retrieve the Spaceship, the Pilot is also automatically fetched. Once again, this post is pretty straightforward and more a loud thinking about Voyage</a> than a real structured tutorial/article. Hopefully it will end up in something useful for someone. If not, you can always enjoy the uber cool hair design in the videoclip of Voyage, voyage from Desireless: video</iframe> MongoDB with Voyage in Pharo 2012-05-24T17:21:00+00:00 Esteban published Voyage</a>, a library for persisting objects in Smalltalk. It uses Magritte</a> to get descriptions from your domain model. At the moment, MongoDB</a> and the image are the two possible backend for Voyage. If you are not familiar with MongoDB and Document based databases, this presentation</a> (~1h) by Jared Rosoff should help you to grasp the differences with the RDBMS world. I wanted to play a bit with Pharo and MongoDB, there’s a MongoTalk</a>, a simple smalltalk driver which works well but is quite low level. I wanted something that can be easily integrated with Magritte. Here’s some dabbling with it and Pharo 1.4 (version 14441). Nothing really fancy, we will just save an object. The Metacello configuration will take care of installation: Gofer it url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; package: 'ConfigurationOfVoyage'; load. ConfigurationOfVoyage project bleedingEdge load: 'Mongo'. </code></pre> Update August 2012 Esteban created two different configuration ConfigurationOfVoyageMongo</code> and ConfigurationOfPierVoyage</code>. You should use the former for loading Voyage: Gofer it url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; package: 'ConfigurationOfVoyageMongo'; load. (ConfigurationOfVoyageMongo project version: '1.0') load: 'Mongo'. </code></pre> We are going to assume you have a default MongoDB setup. repo := VOMongoRepository host: VOMongoRepository defaultHost database: 'voyage-play'. </code></pre> And setup this repository as the default one: VORepository setRepository: repo. </code></pre> Declare a new class. Don’t pay attention to my model, I’m designing the next social network that will bring humans to Mars. Object subclass: #Brolinou instanceVariableNames: 'title' classVariableNames: '' poolDictionaries: '' category: 'Brol' Brolinou>>title ^title Brolinou>>title: aString title := aString Brolinou class>>isPersistent ^true </code></pre> The last one is important. Voyage is now aware that you can persist Brolinou</code> objects. The weird thing is that Voyage currently depends on Magritte 2. I don’t know if you’ve already migrated to Magritte 3 but it bothers me a bit to start a new project with Magritte 2. I’m by no means a Magritte expert, there a probably good reasons to stay with that version. It is maybe that time is scarce and that Esteban is working like crazy on many other projects ;) Anyway we gonna add a description for our title field: titleDescription ^MAStringDescription new label: 'titre'; accessor: #title; yourself. </code></pre> Time to open a workspace and dabble with our model: brol := Brolinou new title: 'Going to Mars!'. brol isNew. "=> true" brol save. </code></pre> Tadadada! Open the Mongo shell or your favorite interface to it (I’m using RockMongo</a>). You should see a new collection. The weird thing is that the new collection is named olinou</code> in the database voyage-play</code>. I was expecting something like brolinou</code>. Remember that we are running the bleeding edge version of Voyage so it’s not that important. You should have an entry that looks like: { "_id": ObjectId("69b4a62c0000000000000000"), "#instanceOf": "Brolinou", "title": "Going to Mars!" } </code></pre> We can see here that a field `#instanceOf" has been added to the record. It is probably used at materialization. You can now query your class to retrieve all the Brolinou instances: Brolinou selectAll. Brolinou selectMany: { #title -> 'Going to Mars!'} asDictionary. </code></pre> To see all the available methods, browse the Voyage-Model-Core</code> protocol in the class Class</code>. The persistence</code> protocol of VOMongoRepository</code> is quite interesting as well. That’s all! Here are the topics I’d like to cover next: Queries</li> Index</li> So far, Voyage will create a collection named after the class. With embedded objects you don’t always want that behavior. There’s probably a way to override that, i’m wondering how it is made.</li> </ul> Edit</h2> The issue with the collection name is caused by the following code: VOMongoContainer class>>defaultCollectionName ^(self label allButFirst: 2) asLegalSelector </code></pre> This decision was probably made because of the lack of namespaces in Pharo. So people prefix their model class with two letters (e.g., WATag, FSLocator, ZnEntity). It makes sense now. Edit two</h2> It seems that the Magritte description is useless in this case. Voyage will happily serialize the title</code> instance variable automatically. See my next post</a> for more. Vancouver Smalltalk Developer Group 2012-05-23T16:13:00+00:00 The first meeting of the Vancouver Smalltalk Developer Group</a> was pretty good! Nine people showed up, which is quite nice considering the size of the Smalltalk community and the fact that it was the first event. Unfortunately I forgot to take pictures, probably a side effect of interesting discussions ;) We got the meeting room of a Waves coffee shop in downtown Vancouver, the venue is allright but there is no projector and we were kicked out of the room at 8.30. The next event is on its way. The date is not decided yet but it will happen between the 11th and 16th of June (tell us what’s better for you in the doodle</a>). If you are in the area, you’re more than welcome even if you’re not a smalltalker. In the future, please subscribe to the Meetup group</a>, the ESUG</a> list or the SCONA</a> list to be in the loop ;) Global package cache & stdin, stdout, stderr on Pharo 2012-05-18T13:17:00+00:00 When loading a package with Monticello, a copy is cached in the directory ‘package-cache’ in your image folder. This is super useful when you need a package that you already have downloaded. Unfortunately, this cache is limited to the image directory. If you need that package in another image which is in another directory, you’ll have to redownload the package. Here’s a little trick to have a global package cache: MCCacheRepository default directory: (FileDirectory on: '/home/fstephany/package-cache/') </code></pre> Of course, adapt the path to your configuration. Thanks Mariano for the tips (original discussion</a>). Another super useful things is the ability to send stuff to `sdtin`, `stdout` and `stderr`. I don’t know if it was present prior Pharo 1.3 but I’ve just discovered how to play with the standard streams: FileStream stdout nextPutAll: 'Yopla' </code></pre> Browse the class side of FileStream for more ;) Limit hard dependencies in your code 2012-05-17T13:31:00+00:00 Igor Stasenko summarizes what he does</a> to avoid coding with hard dependencies in his code: Rule #1. never make more than 1 reference to any class external to your package in your code. an exception is kernel classes. which means, that you are allowed to do `Set new` or `Array new`, in any place of your code but never `SomeFooClass new` more than once. If your code having such dependency, localize it in single method: fooClass ^ FooClass </code></pre> and then use `self fooClass` everywhere.. Like that, if you will figure out one day, that sand moves under your feets, you’ll have to change only single method. :)</blockquote> I never felt the need of doing that when the refactoring browser can rename all that for you but it’s still make sense if you want cleaner code. Thanks Igor :) Migrating to Pharo 1.4 2012-05-01T22:45:00+00:00 You’ve probably heard that Pharo 1.4 is out. This version contains many improvements (as software developers like to say) and some aspects have changed quite a lot. One the Pharo team’s goal is to clean Squeak. Version 1.4 has made some critical steps toward this goal and more than 850 tickets have been closed. Impressive. What is still lacking though is a detailed changelog of all the API changes. Sure, there’s a release note</a> but hey what does Better headless support mean? I’ve switched some of my projects from 1.3 to 1.4. I haven’t tested everything in production yet but here are my first surprises: FS integration</h2> The FileSystem</a> (or FS) library has been integrated. FS is a replacement for the aging `FileDirectory`. Manipulating files is now much easier and the API is less chaotic than its predecessor. The `FileDirectory` is still there for compatibility reasons I guess but you shouldn’t use it anymore. If you used the FileSystem library before, beware that the FS prefix has been changed to “File” (i.e., `FSLocator` becomes `FileLocator`). Update your code accordingly. If your project has a MetacelloConfiguration that loads FS, you don’t need it anymore for 1.4 Startup scripts</h2> That one was missing for quite a long time. Pharo will now look up in your home directory for startup file in the following order: #{image_directory}/startup.st ~/.config/pharo/#{version}/startup.st ~/.config/pharo/general/pharo#{version}.st </code></pre> This has bitten me when deploying an a server. I used to launch my image with the following: exec $VM $VM_PARAMS $IMAGE $STARTUP_SCRIPT </code></pre> where `$STARTUP_SCRIPT` is the path to a `.st` file. That file was named `startup.st`. My startup script was executed twice without I realized it. It took me some time to realize what was going on ;) Beware, it seems that this feature is not reliable (or not implemented?) on Windows. No default browser</h2> Pharo 1.3 used to be shipped with OmniBrowser (OB). This is not the case anymore and the default browser is now the basic one. No advanced features, no refactoring, plain boring. The best choice is to load Nautilus, a browser developed by Benjamin Van Ryseghem. There is a job on the CI build server</a> which contains the latest version of Pharo 1.4 and Nautilus. Unfortunately, I had some troubles with it. When using the build from CI, loading seaside didn’t work. And when I load Seaside in a clean 1.4 image and then loading Nautilus, some strange problems occurs (like the font changes). I haven’t really investigated yet but that smells like bleeding edge piece of software. The browser is pretty cool though and it is definitely a huge step from OB. My muscle memory is still trained for OB, which complicates the transition :p All in all</h2> This release is a good one, the Pharo team did an awesome job and I can’t wait to see what the 2.0 will look like. They apparently changed their release process</a> for a time-based versioning (à la Ubuntu). Time will say if it’s a good choice… Send email from Pharo with Postmark 2011-12-29T17:22:00+00:00 I recently needed to send emails from a Pharo image. There is a SMTP client integrated in the standard libray but I wanted to wrap the excellent Postmark</a> REST API</a>. You can load it from SqueakSource 3</a>: Gofer it url: 'http://ss3.gemstone.com/ss/postmark'; package: 'ConfigurationOfPostMark'; load. (Smalltalk at: #ConfigurationOfPostMark) project stableVersion load. </code></pre> And you can use it like: | email interface | email := PMEmail new from: 'francois@wapict.be'; to: 'francois@yopmail.com'; subject: 'Test Application'; textBody: 'Yeah baby'; yourself. interface := PMInterface new. interface apiKey: 'blopblop'. interface send: email. </code></pre> The implementation is really basic and does not handle attachments at the moment. I use it on a staging application that will probably be in production in January. I will see how it behaves under small load and improve it if needed. edit: you can now attach files to your emails ! Windows Phone 7 2011-12-28T12:54:00+00:00 I’ve written this article in June 2011 and never published it. Now that Nokia has shipped their phones and the Mango (aka Windows Phone 7.5) is everywhere, it’s maybe time to click on the publish button ;) When reading reviews of WP7.5, Microsoft has fixed almost all the issues I had with my LG Optimus 7 phone. Unfortunately, it broke during the (awesome) Dour festival</a>. The phone became crazy and kept rebooting. (In case you are wondering, fifteen minutes of cycling reboots keeps your phone hot). The shop where I bought it did not plan to get any Windows Phone soon so they gave me a Galaxy S2 (almost) for free. While Android 2.3 is packed with wonderful features, it’s not as polished as the WP7 phone I owned but it usually works well. Android 4 is said to address this but I don’t think it will be as fresh and usable than Windows Phone. Anyway, here’s the short review I wrote back in June: I was the first to be surprised when I came back home with a windows phone in my bag. Three months later, it’s time to report. A bit of context: I’m a big fan of Apple products for seven years now (and I was a Linux user before). MacOS X is an impressive operating system: the geek inside me loves UNIX, the end user part of me likes the ‘everything works out of the box’ side of the Mac experience. Long story short, I love this Windows Phone 7. Tiles are awesome. Simple, no gradient, no round corners, ni shiny effect, just the fact. Data-ink ratio is very high, Tuft would be happy.</li> Menus are kept to their minimum. There are not tons of options everywhere. Microsoft provided a very opiniated way of using the phone and they made the right choice almost every time.</li> All in all, this Metro UI is particularly well thought. Navigation follows a consistent pattern through the OS. Third party applications tend to adopt it.</li> Animations are plain right. Very subtle, never too long, they are visually pleasant and serve their purpose very well. They bring a sensation of fluidity and smoothness.</li> No custom ringtones. That sounds ridiculous but it clearly shows the direction taken by the creators of the OS.</li> Actually one of the only possible customisation is to change the dominant color. My favourite is Magenta. The color will be used almost everywhere in your phone. Elegant.</li> The Mac software is simple and easy to use. It synchronises your phone with iTunes' data. Don’t know if Apple appreciates but it works just fine</li> I have mixed feelings about the web browser though. Navigation is fast and fluid but javascript performance and CSS handling sucks at best. The navigation bar disappear when you are in landscape mode. That’s quite weird. Microsoft says it is based on a mix of IE 7 and 8. Fortunately, they will ship IE9 with the next release of Windows Phone. The stuff that could have been added without too much boilerplate:</li> They screwed up with the first update of the OS. It brought copy-pasting but deployment was a nightmare for Microsoft.</li> Notification LED. My android phone had a small LED hiddden in the speaker. Even when you’re phone is in silent mode you can see in one eye glance if you'vre a text or missed a call. very useful</li> No threads in emails. Epic fail.</li> No tethering. Annoying in the train.</li> No multiple calendars when synced with Google Calendar.</li> I cannot find a good Remember The Milk app. WinMilk is way to slow to be usable (yeah, I know, it is open source it is up to me to improve it instead of complaining)</li> </ul> This week, Microsoft unveiled a new version of WP7 called ‘Mango’ or WP7.5. This update brings a lot of new features. Hopefully they won’t screw the whole Metro experience (fingers crossed). All in all, forget Windows Mobile 6.x, Microsoft changed everything. The subtle rename from Windows Mobile to Windows Phone is not innocent. I can’t believe I’ve just said something good about Microsoft software. Legacy projects 2011-12-19T18:51:00+00:00 As a company or freelance developer you have probably encounter the dilemma of taking over somebody else code. On one side you are happy to get new work, on the other side dealing with legacy code can be frightening. Here are some questions you will need to ask when you continue and maintain a project: What kind of client will you get when accepting the project?</li> How was the relation between the previous developer and the client?</li> Where is the project hosted? Do you have control over it?</li> What are the dependencies of the project? Ruby 1.8.6, Rails 1.2? RMagick? Will you have to migrate it to newer versions at some point? Does the client understand that you need to upgrade libraries and frameworks?</li> More generally, is the client aware that software needs maintenance?</li> Will you be the one responsible for old bugs that are discovered after you took over the project? Usually the client sees a bunch a stuff not working once you start to work on the project.</li> Have you considered a code review before accepting the project? Who did it? Someone external? The previous developer (hint: blink in red in your radar)?</li> Will you need to implement big new features? How the previous developer used to bill the client for them?</li> Is the client aware that you will probably be a bit slower than the previous developer when you start working on the project?</li> </ul> Many of these questions sounds stupid or simple good sense but a checklist is never too much when it comes to such a tricky decision. Everybody likes to write new code. Maintaining code is usually less appealing. I love to dig in somebody else code,to refactor it, to understand what the previous developer had in mind when doing it. I like to remove the small imprecisions here and there and to curse when I see useless javascript files or two hundreds lines of commented code. Smalltalk & native UI 2011-12-11T12:26:00+00:00 From time to time, someone on the Pharo mailing list asks how to build a desktop application. A long time ago, Smalltalk was a great way to make desktop apps. drag & drop, rich visual interface, mouse pointer. Yeah, the mouse was quite a big thing. Things have changed. People expect consistency from the software they use. Not only in the look but also in the feel. They want their applications to be tightly integrated with their operating systems. If you’re considering a niche application where people only care about the functional part of the system, that could work. Otherwise I would not bet a penny on a smalltalk dialect. Long story short, don’t use Smalltalk if you want to be the next WordPad or iTunes. I’m not saying that Smalltalk is bad at user interfaces, new UI paradigms are tested with Smalltalk. Croquet</a> and Newspeak</a>, Gaucho</a> are examples of some innovations in user interfaces (one for collaborating in 3D world, the other for IDE and GUI framework). footnote: I actually have to mention that I’ve heard that Dolphin</a> and ObjectStudio</a> runs natively fine on windows. Smalltalk for the Rubyist 2011-12-09T10:55:00+00:00 After my previous post about the Pharo ecosystem</a>, some people asked me more about a comparison of Smalltalk and Ruby. And how a Rubyist could leverage his knowledge when learning Smalltalk. The two languages are class based, dynamic and their supporters like their clean and easy syntax. Actually, Smalltalk is sometimes considered as one of the father of Ruby. They share quite a lot and most of the patterns used in one can be easily expressed in the other. This post does not cover the basic syntax of Smalltalk. If you want to learn it (15 minutes max), wikipedia</a> should be enough. Implementations</h2> Ruby comes in different flavors: MRI, YARV, Rubinius</a>, JRuby</a>, Maglev</a>, etc. So does Smalltalk. The principal difference is that they are no “official” distribution. Every dialect has its own ecosystem and tools. Some are open source, some are proprietary. Choosing an implementation can be a quite challenging task. If you want to go the open source way: Squeak</a>, the most famous implementation. The project has quite a long history. The development seems to have slowed down a bit 3-4 years ago but Squeakers are working hard now.</li> Pharo</a>, a fork of Squeak. The goal of the Pharoers is to produce a clean and industry-capable Smalltalk. It all started when some people were really pissed off by the inaction of the Squeak community. Backward compatibility was a pretext for doing nothing. Pharo moves fast and does not aim to stay backward compatible with Squeak. Many projects still runs on the two without a itch though.</li> GNU Smalltalk</a>, an alien implementation. You can use your favorite text editor with it. It is a clean implementation but it maybe misses a complete environment.</li> Amber</a>, a smalltalk that compiles to Javascript. Pretty young but already impressive. It can be used with Node.js or in the browser.</li> </ul> I’m not really interested in proprietary implementations but there are three big players in that field: Cincom Smalltalk</a>, VA Smalltalk</a>, Gemstone/S</a>. Gemstone is not only a Smalltalk implementation but also an extremly scalable object-database. Actually Maglev</a> is a Gemstone based products. If you’re serious about Ruby, you should definitely give Maglev a look. My favorite implementation is Pharo. I like the energy in the community and its direction. It is for me the best bet for the future. It very similar to squeak but this screenshot of the main menu is enough to convince me. You can follow this thread on stackoverflow</a> to get the opinions of others. The Environment</h2> Here comes the biggest problem when learning Smalltalk. That’s where people usually get lost. Smalltalk code does not lie on a plain text file. There are literally no “code time”, it’s always runtime. It would be like coding in an IRB session. You manipulate objects all the time. Consequences ? You can inspect object in live. You are working with a webservice and want to inspect the answer? Just inspect the response.</li> Change values on the fly. You wanna know what happens if that variable is -5</code> instead of 5</code>? Change its value to see what happens.</li> You can actually code in the debugger. The debugger (or a stacktrace) is not an analysis tool anymore. You can actually code in it. A method is missing? Oops. Create it on the fly and continue the execution from where it failed.</li> Fast tests, all the time. Corey Haines</a> teaches you how to get fast tests</a> in rails. You do not need this in Smalltalk as your web/test/whatever framework are already loaded. Of course, if your tests starts to rely on external depencies (disk/network/etc) without mocking, they’ll get slow. No surprises.</li> </ul> Actually some tools are starting to appear in Ruby. Pry</a> is pretty damn cool Ruby tool. Once you’ll get used to Smalltalk environments you’ll want more. When you load a library in your image, it lies next to your code. You can then read it, inspect it, put breakpoint in it and do whatever you want with it. An image contains your code and all the libraries you want. It acts as a container and is completely independent from other images. Metaprogramming, Object and Classes</h2> Okay, that one is tricky. What do you expect from meta-programming? Adding methods on runtime? You are already in runtime.</li> Handle method_missing</code>? Welcome doesNotUnderstand</code>.</li> </ul> As method_missing</code> in Ruby, doesNotUnderstand</code> must be used carefully. The usual advice applies in Smalltalk. Actually defining a class in Smalltalk is just sending a message (“calling a method” in Smalltalk jargon) to the class Object</code>. Adding a method is also a matter of sending a message to define it. The only difference is that you use tools to do it. Remember, it’s runtime and your environment is the running your code. That living environment comes with great responsibilities. If you try something along Object := nil</code> I guess you’re a footing yourself in the foot. If you want to learn more about the Smalltalk object system, I warmly recommend the chapter 13 of the Pharo By Example</a> free book. If you don’t know that much about Ruby’s object system, I recommend the Dave Thomas presentation</a> at Scotland on Rails 2009. Returns</h2> Methods need explicit returns (with ^</code>). If omitted, the method will return self. You get implicit returns for blocks: the value of the last instruction is the the value returned by the block. If you return (with ^</code>) inside a block, it is a return value for the method. Syntax Convention</h2> Methods name and variables are spelled in CamelCase. Abbreviations are usually avoided. Smalltalk uses keyword based method name (as in Objective-C). Many Ruby libraries/framework mimic this by passing an hash as argument. The tabs vs. spaces does not exist in the Smalltalk community. In every tool, press Tab</code> to indent and you’re done. As usual, just keep the global syntax style of the project you’re working on. Usual suspects</h2> Be careful when using cascades, a common is mistake is the following: programmingLanguages := OrderedCollection new add: 'Ruby'; add: 'Java'; add: 'Haskell' </code></pre> In the end of the execution, programmingLanguages will be the String Haskell</code>. That’s because the method add:</code> returns its argument, not self</code>. To prevent this, send yourself</code> at the end of the cascade: programmingLanguages := OrderedCollection new add: 'Ruby'; add: 'Java'; add: 'Haskell'; yourself. </code></pre> Another trick of the the language is the evaluation order: 3 + 4 * 5 #=> 35 and not 23 </code></pre> Evaluation is done from left to right. Mathematical order is not preserved. Indeed, +</code> and *</code> are simple methods. Smalltalk does not even know (and does not care) that it is executing mathematical instructions. You must use parenthesis to express precedence: 3 + ( 4 * 5 ) #=> 23</pre></div> </code></pre> Version Control</h2> My previous post</a> will explain you how to version Smalltalk code. Do not expect Git</code>, Mercurial</code> or Subversion</code> (although they can be used as backends for Monticello). Conclusion</h2> Once again, this post is inspired by someone else doing the same for Javascript</a> (thanks Greg Spurrier for the link). The Squeak by Example</a> or Pharo By Example</a> books are worth to read. Beware that the tools described in the book are sometimes outdated but the principles are still perfectly valid. The Pharo Smalltalk ecosystem 2011-12-06T03:00:00+00:00 This post is intented to developers who’ve heard that Smalltalk is hot and sexy. A fraction of them have tried to download a One-Click version of Pharo</a> and played a bit with the language by following a tutorial or two. So now they have a taste of Smalltalk but they do not get the entire picture, how the environment work, how people actually build and deploy software with it. If you are one of them, you’ll probably want to take some time to read this :) Images and VMs</h2> If you’ve downloaded a One-Click image, you haven’t experimented with the notion of image and VM in Smalltalk. Actually you have but not in an explicit way, you’ve simply clicked on an icon and got your environment. You’ve maybe ‘Quit and Save’ and when reopening the application you had the same state than when you left. Easy. In pratice, Pharo works with an image running on top of a virtual machine. If you come from another scripting language, it certainly offers a REPL (e.g., IRB for Ruby). Think of the image as a dump of that REPL at a given moment. A Pharo image contains everything: your code, the tools and the libraries. You can load code into it, you can save it and restart it at any moment. This image is closed. That’s why you cannot use your text editor to edit Pharo code (actually you could but you certainly would not want that). The VM is usually something you should not care about. My advice is to use the one given by the Pharo website, it is tested by a Jenkins server and is the one people use the most. In a nutshell: download a VM and an image from the official website</a>. At this moment, the stable version is Pharo 1.3 and the image is CogVM-13307. I personnaly put the VM in the /Applications</code> folder on my Mac. The image comes with a .changes</code> and .sources</code> files. Keep them in the same directory than your image. Beware that the evolutions of the image and the VM are not tight. It is possible that a Pharo 1.3 image will run on a new VM version in two years. To start an image, double-click on it. If your OS does not get it, you can drag the image icon on the VM icon. That should work. Version numbers</h2> When you download the image, you can see the exact version you are downloading: Pharo-1.3-13315.zip</code>. It means that it is the 315th revision of Pharo 1.3. The 13xxx part is redundant with the Pharo-1.3. The VM has currently the name CogVM-Mac-13307.zip</code>. Which means it was frozen with the 307th revision of the Pharo image. Source version control</h2> Your code is in the image. You don’t even have a full text view of your nice classes. How do you persist it? So far, you’ve probably save your image and re-open it later. That’s the best way to lose everything if your image crashes (and that happens). It’s also not really handy if you’re not alone on the project. Monticello comes to the rescue. It is a version control system like Git, Subversion or Mercurial. The only difference is that it does not version files but classes and methods. That’s pretty great for an object-oriented language, isn’t it? Historically, Squeaksource</a> is the GitHub</a> of Smalltalk. It is old, ugly and slow but it works. A more modern alternative is SqueakSource3</a>, which brings Squeaksource to the latest frameworks. There are less projects than in the original Squeaksource but you should use it for your new projects. SmalltalkHub</a> is on its way. It is not stable enough to be used in production but we are all waiting for it :) James Robertson</a> has made two (very short screencasts to help you get up and running. You won’t need more than 4 minutes to watch them. Smalltalk For You, episode 48</a>, you’ll see how to save a package in a Monticello repository. Gives you all the basic information you need to know to use Monticello. Three minutes. That’s it.</li> Smalltalk For You, episode 49</a>, this screencast will show you how reload the code you saved in the previous screencast in a fresh image. A little more than one minute.</li> </ul> Load external libraries</h2> Loading code in your image is pretty easy. Open a Monticello Browser and add the repository from which you want to load code. Et voilà, done. The problem is that sometimes, a package has dependencies. So you end up losing 4 hours only to track the dependencies of the package and to figure out a load order. Metacello was designed to help you. A project can provide a “Metacello Configuration”. This configuration describes the dependencies and the load order of the project. Of course a configuration can load an other one. You can also tag versions of your project. When you want to use a project, the first thing to do is to find its MetacelloConfiguration. As of today, the lookup to find a configuration is: Check if the project exists in http://www.squeaksource.com/MetacelloRepository.html</a>. This repo is a goldmine.</li> If it is not there, check in the project repository if you find a ConfigurationOfTheProject</code>.</li> Ask the Pharo-users mailing list.</li> </ol> If your project is not trivial, you should write a ConfigurationOfYourProject. You can get inspiration from other configurations. I personnaly like the ConfigurationOfFuel. Once again, James Robertson has already covered the subject in his Smalltalk For You screencast series. Episode 82</a> shows you how to load GlorpDBX (an object-relational mapping package for Smalltalk) in a fresh image using Metacello Configuration in a little more than two minutes. Good practices</h2> Ok, so now you know the tools that are used by Pharo developers. Let’s move on to the next critical point: Good habits. New image everyday</h2> As you save your image and reopen it 16 hours later in exactly the same state, you are probably tempted to keep it forever and do all your development in it. So convenient. In theory only. With time, you experiment and create a bunch of stuff you won’t need. You have loaded many external packages and you don’t know anymore which are your dependencies. Your image becomes bloated, it may eventually crash. The best way to avoid rotten images is to get a new one everyday. Download a stock Pharo image (or keep one somewhere locally) and load your MetacelloConfiguration. This will have two benefits: Your image is always clean and not bloated.</li> You know that your code load and works. This way you are sure that your co-workers can load your code and deployment is smooth.</li> </ul> Keep your images organized</h2> I’m sure you’ve already think about it but try to keep your different images organized. it is not hard to end up with dozens of Pharo images scattered across your hard drive. Try to keep things simple. For example, I keep a directory with all my stock images (Pharo 1.2, 1.3, the preversion of 1.4, Squeak, One-Clicks, etc). Choose a convention and stick to it. Syntax conventions & micro decisions</h2> Follow the conventions used by many Smalltalkers. Naming conventions as well as indentation. A very good read is Smalltalk Best Practices Patterns</a> by Kent Beck. Follow this style your code will follow Smalltalk idioms. Actually, the patterns discussed are also valid for Ruby. So go and grab your copy. Conclusion</h2> I wanted to write this guide for a long time now. This article</a> for Python convinced me to post it. I hope it will be useful for some folks who want to try Smalltalk (and its Pharo implementation). Feel free to email me or to comment if you have any question or suggestion. If you are a Ruby developer wanting to learn Smalltalk, please drop me an email</a>, I need your help for future posts ! Available for work! 2011-11-16T10:54:00+00:00 As I'm getting more and more addicted to Pharo Smalltalk, I would like to offer my services as a Smalltalk developer. I'm a freelance contractor with a belgian VAT number but I also have a valid working permit for Canada (I'm currently living in Vancouver, BC). If you are looking for a part-time developer with a Ruby/Rails/Javascript background, do not hesitate to contact me (even for a chat), I'm all ears! Pharo development 2011-10-10T14:34:00+00:00 I sometimes wonder why Pharo</a> has such difficulties to get a stable version. Even when a release comes out, it is not that rock solid. When building an image, you get code from various locations. Integrating everything together seems hard. For example, a package will use a syntax highlighting mechanism, which will be different that the one used in another package. Different shape, different quality, different patterns, it is hard to get the same foundation for everything when you cover many areas: gui, drawing, threads, locks, filesystem, etc. Smalltalk acts as a whole operating system, it is one of its strength but also one of its weakness. It sounds wrong when you are used to the Unix philosophy where one tools equals one function. Smalltalk breaks that and want to do everything by itself. It becomes nice when you want to do something that crosses different layers (delayed_job</a> would be almost useless in Smalltalk); you start your image and everything runs inside it. You stop it, everything stops. Easy. The drawback is obvious: Smalltalk environments tend to reinvent the wheel all the time. When you consider this, you start to realize the tremendous amount of work done by the developers. They proceed by baby steps but they are going very far… And I can’t wait to use Pharo for system scripting</a> Ruby frustration 2011-09-30T12:15:00+00:00 The more I code in Smalltalk, the more I find the flow of developing in Ruby annoying. What I really miss is a good way to navigate code, the debugging facilities and the runtime aspect of a Smalltalk dialect. Code navigation</h2> The browser is the standard way to browse code in Smalltalk. While it can be seen as cumbersome and ugly (in the look and the feel) compared to a native UI or a text editor, experienced smalltalkers have a love-hate relationship with their browser. When using it, you do not need to have 45 tabs opened in your web browser. Almost all the documentation you need is right there in front of you. Browsing the senders and implementors of a method is so easy and convenient. When you come back to a text editor and Ruby code it’s just a pain in the ass to perform changes in your code. As a developer you will spend (by far) much more time debugging and reading code than writing it, why not have a dedicated tool to browse it ? Runtime</h2> One of the most frustrating point when developing in Rails is how slow it becomes when your Gemfile grows. Running the test suite is so slow, it feels like the old ‘code-compile-run’ cycle is back again. It’s not the tests that are slow per se but loading the environment. Each time you run a test, you wait for Rails to start while the actual time spent in the test(s) is negligible. Very frustrating when doing TDD. There are some tools to overcome this problem but it’s sometimes quite hard to get them working (more on this in a later post). Debugging</h2> Take the browsing tools and the always-runtime feature and you get easy debugging. The TDD flow get much better when you can create methods on the fly, navigate the stack and change the state of your object on the fly. In Rails, I’m used to run the test, see it fails, switch to my text editor and re-run the test. Tools like Pry</a> makes things much more smooth but they are quite far from a live debugger. Closing</h2> This post is already far too long for and probably not very well illustrated but I hope you get the idea. I’m not saying that Smalltalk is better; all the goodness mentioned before have their drawbacks, mainly when it comes to deployment. As your code is always running, it can be quite cumbersome to deploy it on a server in a fresh state. There are tools to help but they are not as nice as what you get in the Ruby world. A lot of smalltalkers seem to have their own recipes to deploy. It can be quite disturbing for someone coming from Ruby. Anyway, I gonna try to illustrate my arguments in the next posts. Thanks for reading ! Seaside session timeout 2011-08-28T13:27:00+00:00 As usual, this post is most a reminder for myself but it can be useful for others. In previous version of Seaside (prior to 3.0), it was possible to change the default session timeout by using: application preferencesAt: #sessionExpirySecond put: 1200 </code></pre> It has changed with Seaside 3.0 and looked a bit more complicated now: application cache expiryPolicy configuration at: #cacheTimeout put: 1200 </code></pre> If I’m missing something, tweet me</a> :) Metacello configurations readability 2011-08-24T07:46:00+00:00 I’m I always spec spec ]. </code></pre> Am I the only one ? Too much Smalltalk 2011-08-13T12:15:00+00:00 polishing a very small package to interact with ogone</a>, a payment platform, from a Seaside</a> application. So it’s time to write a Metacello configuration to share it easily. have hard time to read Metacello configurations and wonder if a vertical alignment wouldn’t help. Basically, I find this: ound-color:#2b303b;color:#c0c5ce;">baseline10: spec spec for: #common do: [ spec blessing: #baseline. repository: 'http://www.squeaksource.com/ogone'; package: 'Ogone-Core'; package: 'Ogone-Seaside-Example' with: [spec requires: 'Ogone-Core']; package: 'Ogone-Tests' with: [spec requires: 'Ogone-Core']. group: 'default' with: #('Core' 'Seaside-Example' 'Test'); group: 'Core' with: #('Ogone-Core'); group: 'Seaside-Example' with: #('Ogone-Core' 'Ogone-Seaside-Example'); group: 'Tests' with: #('Ogone-Core' 'Ogone-Test') ound-color:#2b303b;color:#c0c5ce;">baseline10: spec spec for: #common do: [ spec blessing: #baseline. repository: 'http://www.squeaksource.com/ogone'; package: 'Ogone-Core'; package: 'Ogone-Seaside-Example' with: [spec requires: 'Ogone-Core']; package: 'Ogone-Tests' with: [spec requires: 'Ogone-Core']. group: 'default' with: #('Core' 'Seaside-Example' 'Test'); group: 'Core' with: #('Ogone-Core'); group: 'Seaside-Example' with: #('Ogone-Core' 'Ogone-Seaside-Example'); group: 'Tests' with: #('Ogone-Core' 'Ogone-Test') I’m using way too much Smalltalk these days, I find myself typing: @articles do |each| # do something with each end </code></pre> instead of: @articles.each do |article| # do something with article end </code></pre> when coding in Ruby. Stupid brain… Pharo Smalltalk experience report, part I 2011-08-11T11:34:05+00:00 Hi there, I’d like to share some of my latest experiments with Pharo</a>. This post is not very well structured and certainly needs some polishing but time is scarce. I use Ruby and Rail for my daily work at agilitic</a>. I’ve always dabbled with Smalltalk (Squeak then Pharo) and wanted to build a real world project with it. Wapict.be</a> was the ideal candidate: not too big while not trivial. The idea behind wapict is simple: become the reference of photography in Wallonie-Picarde</a>, a region of Belgium. We sell stock pictures in digital or printed format, provide photographers for events and experiment with photography techniques… It started with a simple presentation website and has now some nice features for photographers. A lot more is planned (e.g., buy online with credit card) but the project is advanced enough to do a first post about it. Stack</h2> Currently, wapict is running with: Pharo 1.3</li> Seaside 3.0.5</li> XMLSupport</li> Fuel 1.4</li> Zinc HTTP server</li> </ul> All managed via Metacello</a> Configurations. The project runs with the Cog VMs</a>. Development is done on MacOS while the staging and production servers are running Linux. A big problem with Pharo is that there are no official supported VMs. You are there on your own and choosing a suitable VM can be tedious. Hopefully this will change in the future. Persistence</h2> The traffic is quite low and a single Pharo image can handle the load while sipping a coffee. Persistence is primitive right now: I serialize everything with Fuel on disk. Nothing really fancy but it works well for what I need. Pictures are stored on disk and are served with Nginx. The originals are kept private and are not accessible from the public. Deployment</h2> At work we use Git + Capistrano or Vlad to deploy our rails applications. My usual flow is as simple as: git pull git commit -am "fixed bug #456" git push cap staging deploy </code></pre> and hopla my code is in staging. Once validated, `cap production deploy` deploys on the production box. Easy. It seems that there are no equivalent on Pharo or at least there are no common workflow, everybody has his own recipe to roll out new code. I have added a link in the admin section that loads the latest stable Metacello release available. So my deployment flow is: commit modified packages</li> update and commit metacello configuration</li> login to the application and click on the update link.</li> </ul> Not too bad but I have to leave my Smalltalk environment to deploy. I’ll probably create a small webservice to perform administrative operations on the deployed image. Tools</h2> I only use the tools shipped with Pharo 1.3. Nothing really fancy but they work well. The default for code highlighting and code completion suit me. I rebuild my development image as often as possible. Two benefits: I’m sure the whole project is easily loadable in a fresh image all the time and the mess I introduce in my image when developing is cleaned. Conclusion</h2> All in all, i’m quite happy with Seaside and Pharo. It is really refreshing to work with those when doing Ruby and Rails all the day. I cannot stand Rails when it comes to flow anymore. It just doesn’t feel right. I love to develop web applications with Javascript: I can code the behaviour much more easily than with plain HTTP requests and I feel this kind of joy when developing with Seaside. What I really miss though is the possibility to login and open an IRB on a server. That’s quite dangerous in production but it helps a lot when checking the state of an application. What would be really nice to have is a set of remote tools to browse and debug an image from the outside. Some uses RFB to do that but I find it clumsy and slow. I’ve recently discovered tODE</a>, a development environment that runs on top of Seaside, I haven’t checked it yet but Dale Henrichs use it for 80% of his development. All in all, my dream is pretty simple: Pharo 1.4 with Ring</a>, Coral</a> and remote tools</a> =) Dynamically add/remove the Seaside's toolbar on an application 2011-07-13T14:04:00+00:00 I wanted to display or hide the tool bar on a Seaside application. It turned out to be pretty simple. To remove it: app configuration at: #rootDecorationClasses addAll: #() removeAll: (Array with: WAToolDecoration) </code></pre> And to show it: app configuration at: #rootDecorationClasses addAll: (Array with: WAToolDecoration) </code></pre> Another useful snippet to retrieve an application from its name: WAAdmin defaultDispatcher handlerAt: 'wapict' </code></pre> Seasiders won’t find this exciting but this post is more a reminder for myself than anything else. If I’m doing something overcomplicated for nothing, shout my ignorance in the comments ;) Pharo mailing list weekly summary #6 - Migration ! 2011-03-28T13:08:00+00:00 Hey there, As said earlier, the Pharo mailing list weekly summary is now hosted on the main Pharo website</a> (which is powered by Cmsbox</a>). The editing porcess is quite different from what I'm used to. Neat for someone who is not computer savvy but disturbing for someone who writes everything with Markdown! As usual, I've probably forgotten some important topics, so do not hesitate to comment ;) Pharo mailing list weekly summary #5 2011-03-12T06:48:00+00:00 Once again, the week was very busy in the Pharo mailing list. It seems that Pharo 1.2 release is imminent. I skipped a massive amount of threads in this summary. If I removed something important for you, just shout and I’ll edit this post. Next week, the Pharo mailing list weekly summary will move to the official Pharo website</a>. Yeah ! Events</h2> Deep into Smalltalk</a> took place this week, about 45 people attended. It seems that Mariano enjoyed</a> it very much! Presentation slides are available and courses were recorded. Videos are not there yet but I’ll update this post as soon as they are.</li> </ul> Announcements</h2> Doru</a> announced the Glamorous Tool Project. The goald is to build a set of Smalltalk development tools based on Glamour</a>. Is this the future of Pharo development tools ? full thread</a>.</li> There is now an issue tracker for Cog</a>. full thread</a></li> Esteban released a new Cocoa VM: 5.7.4.1. This is a non Cog VM. This release adds no feature but small steps are better than big jumps. full thread</a></li> Umezawa-san told us that SIXX now works on Pharo 1.2 and Squeak 4.2. full thread</a></li> InterpretorSimulator is now working with the latest images. Pavel warned us that it is far from perfect that it should work with small headless images. full thread</a></li> Benjamin built a new Morphic widget: “SwitchableTreeWidget”. It should works fine on Pharo 1.2 (expect problems with 1.3). Load it and tell him what you think. full thread</a></li> </ul> Discussions</h2> There are some discussions about using the SqueakSSL plugin with Pharo. That would help to use HTTPS. At the moment, stunnel</a> is a possible solution. full thread</a></li> There are plans to bring Pharo in the Apple Store. The discussion moved to Apple vs the rest of the world and the future of computing and licensing questions. full thread</a></li> Hilaire asked how to get bigger cursor in Pharo. Apparently Torsten has worked on this. full threads here</a> and there</a></li> Laurent is doing TDD for GUI development. There are no special tools for this and Laurent struggled a bit with `#visible` which always returns true. Ben showed the trick to detect if a window is closed. full thread</a></li> Stef tried to install OSProcess in his image and ran into trouble. Beware that you need a VM with the OSProcess plugin. full thread</a></li> Alexandre explained different solution on how to run Smalltalk in a web browser.full thread</a></li> Hilaire ran into trouble when installing DejaVuBitmapFonts on Pharo core 1.3. Fernando shared the snippet he uses. full thread</a></li> Problems with the integration process and the Hudson server for 1.2. The Great and Perfect Release Cycle is not an easy goal. full thread</a></li> </ul> That’s all folks, see you next week ! Pharo mailing list weekly summary #4 2011-03-05T13:03:00+00:00 Here is the weekly summary of the Pharo project mailing list. If I missed something or say something wrong, please shout at me in the comments. My hightlights of the week: at least three different project are in the tracks for a squeaksource replacement. Pharo 1.2 is almost out but everybody feels the need for a better infrastructure/process. If you want to get involved on this side and if you have enough time, do not hesitate to send your ideas and contributions. Events</h2> Pharo Sprint in Lille. Saturday 12th March. Tell if you plan to go ;) full thread</a></li> The sprint in Bern went very well. You can get an overview of what happened during the sprint on Twitter</a>. To keep it short, Camillo worked on KeyMappings (see this thread</a> for more info), Lukas playing WeakAnnouncements and OB. Adrian, Jorge and Toon started a debugger based on Glamour. They worked hard to decouple the model from the GUI. Mircea built a new widget for searching multiple categories of items in the same time. All in all, Glamour becomes more and more important in Pharo. full thread</a></li> Stephan and Diego participated in Eindhoven startup weekend</a>. They got the innovation price. I could not find more information on the event website :/ full thread</a>.</li> </ul> Releases</h2> New release of Dr Geo II: 11.03</a>. full thread</a></li> Olivier released a LDAP package</a> and a tutorial</a>. It is known to work on Pharo 1.2rc. full threads here</a> and there</a>)</li> Pharo 1.2 should be released. The infrastructure should be improved. At the moment time is lost in Metacello configurations for external packages. Stef reminds us this fact and want to see 1.2 final soon. One solution pushed by Doru would be to set a hard deadline one month before the release. Packages that do not work are removed from the distributon. Laurent pointed that the Linux process could also be a goot candidate. full thread</a></li> Alexandre reminds us about the existence of SilverSmalltalk</a>. full thread</a></li> </ul> Users</h2> More information about Squeaksource 3 on a thread. Nobody have heard about it before. As we have seen last week, the future looks promising. full thread</a></li> There are some discussions about the state of OpenCroquet</a> (now known as OpenCobalt</a>). (full thread</a>)</li> Good thread on TDD. How many time should spend on tests?. Laurent gave a nice reference to Dave Astels book</a>. If you dont know TDD or find it difficult to apply in practice, read the full thread</a></li> Good question from Edouard. He pointed a stupid method: 2 days vs. 2 day. The latter evaluates to the duration of 1 day. full thread</a></li> Dennis asked if it is possible to use russian fonts with the CogVM. full thread</a></li> nullPointer experiences a very slow package loading on Windows. Mariano reminds that antivirus could be the root of the problem</a>. full thread</a></li> Alexandre asked what Coral</a> is about. Documentation is lacking but according the authors it should work. The only tutorial</a> you will find about it is written in french and does not go very deep. full thread</a></li> Stef explained to Miguel how to get a diff between to versions on Monticello. It is the kind of thing you will obviously need one day. Bookmark this post ;) full thread</a></li> Laurent discovered that SSL is not supported on Pharo out of the box. Sven mentioned SqueakSSL</a> but it does not seem to work on Pharo (MacOS and Linux seem problematic as well). Esteban proposed to use stunnel</a> to create an SSL tunneling proxy. Not very elegant and straightforward but it works. full thread</a></li> Olivier asked if there are any documents on how to create GUIs in Pharo. Pharocasts</a> were mentioned and Bill explained briefly the born of Morphic and Polymorph. full thread</a></li> Stef struggled to load Magritte</a> without Seaside</a>. He gave the snippet: Gofer it renggli: 'magritte2'; package: 'ConfigurationOfMagritte2'; load. (ConfigurationOfMagritte2 project version: '2.0.6') load: #('Core') </code></pre> </li> </ul> Internal and discussions</h2> Dale did a solo sprint to fix the failing tests in Metacello and released a new version. full threads here</a> and there</a>.</li> Stef introduced RPackage, a rewrite of PackageInfo. full thread</a>. More discussion about it in this other thread</a>.</li> Stef continues his war against uncommented classes. It is sometimes very difficult to use a class/package/framework when you do not know where to start. full thread</a></li> Discussion about the Azul Pauseless garbage collector</a>. If you are into the VM things, you could be interested with how it compare with the VisualWorks garbge collector. full thread</a></li> Marcus have some news from the Hudson front. They now have a Mac (so mac VMs will probably soon get the benefits of the continuous integration server). The Cog Unix VMs are also continuously built. And there is a new build for Project Sista. full thread</a></li> Eliot wrote a blog post</a> about JIT. full thread</a></li> Stef warned the community about XXX. He seems to approach people with (crazy) business plans. He sent proposals to VCs where he mentioned virtual key team members who are in fact not related with him. German did not have bad experience with XXX. Anyway, be careful if you’re approached by a suspicious VC.</li> Pavel opened a ticket</a> to get pangrams for various language. full thread</a></li> Hilaire wants to get Locale works with a CogVM (to use it with the underpowered XO laptop). If you want to play with GDB and to dig into the VM the thread should interest you. full thread</a></li> SqueakDBX</a> will get slots for SummerTalk</a>. Three mentors, three students. Very good news for this project. full thread</a></li> The state of Smalltalk on tablets and mobile in this thread</a>.</li> Benjamin announced that he (with Igor) managed to get a new Smalltalk kernel based on Pharo which is 2.2Mb and includes 230 classes. Impressive. This is very important to reach one the Pharo’s goal: have a minimal kernel from which needed packages are loaded. full thread</a></li> </ul> As usual, a lots of bugs were fixed and technical details were discussed both in the mailing list and in the bug tracking system</a>. Pharo mailing list weekly summary #3 2011-02-24T12:02:24+00:00 End of week, time for the weekly Pharo digest. Following Ken Brown’s suggestion, I’ve renamed it weekly summary to avoid the confusion with the digest you automatically get from mailing list servers. As I was on holidays, the summary will be short this week. If I missed something really important, let me know, I’ll edit this post. Events</h2> Pharo sprint organised</a> in Bern this Saturday (26th October). The taks of the day is to discuss and improve the Pharo IDE. Anyone can join (Smalltalk newcomers are welcome).</li> </ul> Announces</h2> Moose</a> is available in version 4.3. Moose is a platform for software and data analysis. (the announcement</a>)</li> Miguel updated the configuration of OSProcess. The confifuration takes the symbolic versions</a> into account. OSProcess provides access to operating system functions (full thread</a>)</li> Benjamin wrote a Messenger application to run inside Pharo. Hopefully that could help the developers to communicate when working on Pharo. (full thread</a>).</li> Laurent wrote a simple XML browser</a>. Very handy ! (full thread</a>)</li> Alexandre announced MetacelloBrowser</a>. This tool seems to be the best friend of Metacello. (full thread</a>)</li> </ul> User</h2> Adrien asked how to load OmniBrowser in PharoCore 1.3. Guillermo gave the magic command ;) (full thread</a>)</li> Hilaire asked how to change the default font size (he is working on the XO laptop). It is always the kind of tips you eventually need. (full thread</a>)</li> He also got some problems with the Cog VM and the locale plugin. (full thread</a>)</li> Stef asked how people reify XML and objects. Using XMLParser is always the same the same boring work. full thread</a></li> Olivier asked how to change the Pharo logo in the IDE. This is also the kind of simple question that you will probably ask one day. (full thread</a>)</li> </ul> Pharo</h2> Mariano is back after 25 days of holidays without internet. I guess I’ll have much more work for my weekly summaries now ;)</li> Stef continues to comment FileSystem and asked the opinion of the community on some point. (full thread</a>)</li> The virtual sprint for Pharo 1.2 was a bit hard to organise because of timezones (doodle</a>). I have no idea if it was successful though.</li> Squeaksource</a> is down more and more often these days. As usual, people talked about possible replacements. There will be at least one alternative (Esteban has something, The Iliad guys and Esug are working and I’ve heard about a possible Squeaksource 3). Read the (full thread</a>) if you’re interested. Another thread</a> can also be a good read in you are in the version control thing. With the success of Github</a>, it is crucial from a community perspective to have a nice place to host our beloved source code.</li> Another consulting company said</a>:</li> </ul> Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments.</blockquote> You can imagine the reactions in the mailing list ;) full thread</a> State of Magma in Pharo by Miguel. Magma is an object-oriented database. thread</a></li> </ul> Thanks for reading ! Pharo mailing list weekly digest #2 2011-02-18T08:09:00+00:00 End of the week, time for the Pharo weekly digest. This week was quite busy on the mailing list, if I overlooked something important, please comment this post. At some point, this digest will probably be hosted on the main Pharo website</a>. If you want to help, you are more welcome ! I’ll be absent until Wednesday (Italy!), so I’ll probably miss some threads for the next digest :/ Pharo promotion</h2> The Pharo board calls for Pharo support in the industry. It wants to create a legal infrastructure to collect funds to perform engineering tasks. The end goal is to streghten Pharo. The consortium is not limited to research groups and companies; individuals are welcome! If you are interested in Pharo, download the letter, sign it and send it back. It is crucial to get a stronger open source Smalltalk. Beware that there are two versions of the letter, be sure to get the latest one. See the thread</a></li> Stef created a LinkedIn group</a> for Pharo. It is quite successful (76 members so far).</li> </ul> Events</h2> Laurent proposed to do some virtual sprint next week from monday to wednesday (evening – France timezone). Check the Doodle</a> if you want to join. (full thread</a>)</li> </ul> Misc</h2> Discussion about the new GUI visual designer</a> developed in HPI. This GUI designer targets Squeak but could be porter to Pharo. If I understood correctly, the authors use Signal</a> while Pharo has an explicit preference for Announcements</a>. The discussion moved to the old debate about GUI construction (should we use something like XML to describe a user interface ?), on the topic of how to integrate a big framework into Pharo and how to serialize smalltalk code. If you have followed the thread and if I missed something, please comment ! (full thread</a>)</li> There was a doubt that the introduction of the Hudson build server was putting too much stress on Squeaksource (which is clearly unstable). Stéphane mentions a new cool server. I once heard about a SqueakSource-like project written in iliad</a> and running on top of (GNU Smalltalk)[http://smalltalk.gnu.org/</a>]. Is there a correlation ? (full thread</a>)</li> Janko announces a new version of Aida: Aida/web 6.2 Spring edition is out. Aida is a web framework written in Smalltalk. Janko uses it in production for years now. It is good to see that things are also moving outside the Seaside sphere. (full thread</a></li> A recurring question on the Seaside mailing-list is how to make a multilanguage (I18n) application in Seaside (or Smalltalk in general). Sebastian wrote a blog post</a> some time ago to explain his approach. There is a dedicated chapter in the collaborative Pharo book</a> as well. If I remember well, some others do not follow the same approach. Please comment if you do.</li> A very important issue</a> was reported and closed.</li> Two new success story were added on the website: a workflow platform called Issys Tracking and DrGeo, a scriptable tool used to teach geometry and mathematics in high school. More info on the Pharo Website</a>.</li> The Cog Unix VM is now built with Hudson. The RMoD Team</a> in Lille will soon get a Mac Mini to build the Mac VMs. (full thread</a>)</li> A good reminder of how to call an external executable from an image. (full thread</a>)</li> Dale explained how to load the latest Seaside in Pharo 1.2. Very nice and clear post. (full thread</a>)</li> RPackage</a> is now built</a> on the Hudson server. According to ticket 3609</a>, RPackage wants to replace PackageInfo.</li> Awesome news from the Cloudfork</a> project: OpenID and OAuth support in Smalltalk. More info on a dedicated blog post</a>. This project will help a lot when it comes to integrate external APIs.</li> The state of WeakAnnouncements was discussed in this thread</a>.</li> Huge¨ thread could we agree to remove caseOf: and caseOf:otherwise:. I reckon that I didn’t follow the whole stuff but the conversation seems interesting for those enlightened enough to understand. The discussion covers the new compiler Opal. (full thread</a>)</li> Olivier tries to use the LDAPlayer</a> in Pharo. He needs to send requests to an LDAP server for a Seaside application. (full thread</a>)</li> German gave us a state of the XMLRPC Project</a> which is funded by ESUG</a>. He will focus on Pharo 1.1.1 and 1.2. It is broken in Squeak 4.2 at the momend.</li> Levente proposed a fix</a> for the UUID plugin problem. That will surely cures the headaches of some people.</li> Nicolas pointed some stuff in the String API and possible replacements to make it more smalltalkish. (full thread</a>)</li> HwaJong Oh works on a COLLADA</a> file parser and wants to render it with AlienOpenGL</a>. Fernando said that he has stopped to maintain the AlienOpenGL package but that it should be complete and stable enough to perform the task (full thread</a>)</li> Guillermo updates us about the state of Pharo 1.2. Hopefully we’ll see the official release quite soon ;) (full thread</a>)</li> Fernando likes the PragmaMenuBuilder. You should look at it if you haven’t yet. The discussion moved to the local and global searches for pragmas. (full thread</a>)</li> </ul> See you next week ! This week in the Pharo-Project mailing list 2011-02-11T13:47:00+00:00 In the following weeks, I will try to provide a weekly digest of the activity going in the pharo-developer mailing list (and sometimes some bits from the Seaside mailing list). This digest will be biased by my own priorities and usage of Pharo. There are chances that the commit you are waiting for ages that fix this broken hidden property in Pharo will not be part of my digest. Do not hesitate to comment if I forgot something important. Laurent launched a new game last week: Comment of the Day Contest. The principle is simple: every day a class without comment is randomly chosen. Mailing list participants propose a comment and at the end of the day, the best comment is integrated. It has generated some nice discussions so far.</li> The Hudson server</a> now builds a Seaside and runs all the tests in the Pharo 1.2 build. Continuous integration is definitely the big new thing in the Pharo community.</li> Esteban wrote a new article about the Reef framework</a>. Simply put, Reef is a framework on top of Seaside that let you build dynamic components.</li> Joachim announced the release of JNIPort 2.0</a>. This library allows you invoke Java code from Smalltalk. The big change of this version is the port to Squeak/Pharo (previous versions were only running with VisualWorks).</li> Tony published</a> a great tool to manage external files with Monticello. When writing web applications you often have javascript/CSS/png files hanging around. It can be a mess to deal with Monticello on one side and Git/SVN on the other. TFFiler</a> puts everything into Monticello. Very handy.</li> New COG VMs are available: SimpleStackBasedCogit</a> and StackToRegisterMappingCogit</a>. The latter one is faster but SimpleStackBasedCogit still exists just in case people find bugs with the StackToRegisterMappingCogit that are not in SimpleStackBasedCogit. SimpleStackBasedCogit is “mature”. See the whole thread</a> for more technical details. Those VMs are no longer one-way street. With previous releases, once you had saved an image with a Cog VM you could not open it in a regular VM anymore. This is no longer the case.</li> Guillermo shared a nice trick</a> to push and load all versions to/from Squeaksource with Gofer</a>.</li> Oscar posted a link to a draft chapter about the Settings Framework</a>. It will be included in Pharo By Example 2</a>. Comments are welcome.</li> There was a discussion about syntax highlighting for Smalltalk code in HTML pages. Laurent uses highlight.js</a> on the PharoCast website, Max Leske wrote a a brush for Syntaxhighlighter</a> and Nick pointed that Pygments</a> supports Smalltalk syntax.</li> Stephane announced that the talk of the Deep into Smalltalk school</a> will probably be recorded. Deep into Smalltalk is five days of lectures about advanced Smalltalk topics given by a great selection of speaker. Make sure you attend if you’re interested by VMs, sockets, FFI or C-Smalltalk interactions.</li> Stephane decided to bring FileSystem into Pharo for real and posted a roadmap of what would be cool to have this package.</li> PharoConf in Annecy. Lots of tickets were processed. Congrats !</li> Marcus gave the state</a> of the Hudson build server for Pharo and related project.</li> </ul> Of course, there were a lot of bug fixes and improvements. See you next week ! Javascript, The Good Parts 2011-01-11T13:08:00+00:00 I've just finished to read Javascript: The Good Parts</a> of Douglas Crockford</a>. If you’re doing Javascript development you should read it if you haven’t. This book is not a definitive guide to Javascript but will show you which part of the language to avoid if you want to eliminate a whole class of problems. Here are some striking (at least for me) examples: '' == '0' // false 0 == '' // true 0 == '0' // true </code></pre> That’s because == tries to coerce the values if they are of different types. return { status: true }; </code></pre> Will not return an object with a `status` field. It will return `undefined`. Do you know why? Another nice one is the `parseInt()` function. parseInt('07') // returns 7 parseInt('08') // returns 0 parseInt('09') // returns 0 </code></pre> That’s because when the first character of the parsed string is a zero, it is evaluated in base 8. Seriously. In javascript. A high level language. Wow. Don’t worry, the book is not only a compilation of the weird design choices of Javascript. It will guide you through a world without global variables and will show you how to use functions to create modules. You will learn to master the prototypal object model and understand why the `new` construct in Javascript is evil. Highly recommended. HEMA Packaging & Design 2010-12-07T11:11:00+00:00 I've always liked HEMA shops. They basically all you need for everyday life. From candies, to socks through contact lenses, you always find what you need. Many of those goods and their packaging are greatly designed. I recently bought an economical light bulb. The packaging is great. Check how informations are displayed. The socket size (E27) is on the socket. The luminosity on the light bulb. Simple and beautiful. No plastic. Now compare it with that. HEMA has a great sense of functional design. Unfortunately, not all their products get the same love. Here is for example halogen lightbulb (no, I don't own a lightbulbs collection) package. Sorry, it is open but I needed some light to shave this morning. The package is simple but it looks like any other brand. And it has unnecessary plastic. Their products reminds me an other line of products from Monoprix</a>. The packagings were full of puns about the product. I'm quite receptive to this kind of attention from the makers of the products I buy. Are you ? The ubiquitous Bancontact 2010-11-01T02:44:00+00:00 I strongly believe that one day we will ge the zero-note wallet. Your debit card (or your phone, or the RFID chip implanted in your arm</a>) will take over notes and coins. </div> In Belgium, the main actor in the debit card market is Bancontact/Mistercash. It is virtually anywhere. I had my croissant and coffee in Le Pain Quotidien</a> this morning and tried to pay with Bancontact. The lady told me that I could not pay if the order is less than10€. What ? How many persons have a +10€ breakfast ? I went to the local McDonalds to have another (much cheaper) coffee. Big sign on the cash machine For your comfort and our safety, pay by debit card. Ok. Fine. When I gave my card, the cashier showed me sign in his back. No Bancontact under 10€. Coffee is 1.75€. He let me pay by card but still. What's wrong with Bancontact ? Are the fees per transaction so high that shops lose money when the transaction is less than 10€ ? If they want to be ubiquitous why are putting such a high barrier ? Design is more than pretty picture 2010-07-06T01:58:00+00:00 10 Things CEOs Need to Know About Design </a> </embed> </object> </div> Talk benefits, not features</div> </blockquote> Is my favorite quote of the presentation.</div> Seaside WAAnchor fun 2010-06-14T13:10:00+00:00 I’m currently playing with Seaside</a> (a Smalltalk web framework) for a pet project. As you maybe know, Seaside is, by default, not very friendly with URLs. I wanted to have bookmarkable URLs for user convenience and for search engine. Ramon Leon explains how he managed to get nice urls for his blog in a super-interesting blog post</a>. When playing with WAAnchor methods, I fought with a weird behaviour: html anchor callback: [self moveToPage: page]; useBaseUrl; extraPath: page slug; with: page title. </code></pre> did not work, while html anchor useBaseUrl; extraPath: page slug; callback: [self moveToPage: page]; with: page title. </code></pre> worked fine. Can you see the difference in these two snippets? The reason of the resulting bug is quite simple but is hard to spot when you’re not careful: the method `useBaseUrl` should always be the first to be called in a method cascade on a WAAnchor. Indeed, both `extraPath:` and `callback:` will affect the url of the WAAnchor while `useBaseUrl` will reset it. This reset will cancel all the operations you’ve done before on the url of the WAAnchor. Moral of the story: beware of side effect (or How I Learned to Stop Worrying and Love Functional Programming) Better, Faster, Stronger 2010-04-02T07:17:14+00:00 Web development is a quite hot topic for developers these days. Some think that the web is the future and that native apps are a relic of the past. I would not say that it is that simple (iPhone/iPad apps anyone?) but it is clear that webapps work well for many tasks. Some years ago frameworks started to appear in order to facilitate the development of web applications. They promise faster development time, more robust application and easy maintenance. We all know that a silver bullet does not exist in software development but it's kinda funny to see what all those frameworks promise. Here are some excerpts from some website of them. Spring</a> (Java)</h2> Spring delivers significant benefits for many projects, increasing development productivity and runtime performance while improving test coverage and application quality. </blockquote> CakePHP</a> (PHP)</h2> CakePHP enables PHP users at all levels to rapidly develop robust web applications. </blockquote> iliad</a> (Smalltalk)</h2> Iliad is a Smalltalk web application framework. It is designed to be simple and make web development as effective as possible. </blockquote> Catalyst</a> (Perl)</h2> Catalyst will make web development something you had never expected it to be: Fun, rewarding and quick. </blockquote> Symfony</a> (PHP)</h2> It [Symfony] provides an architecture, components and tools for developers to build complex web applications faster. </blockquote> Ruby on Rails</a> (Ruby)</h2> Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beatiful code by favoring convention over configuration. </blockquote> Pylons</a> (Python)</h2> Pylons is a lightweight web framework emphasizing flexibility and rapid development </blockquote> Django</a> (Python)</h2> Django makes it easier to build better Web apps more quickly and with less code. </blockquote> Seaside</a> (Smalltalk)</h2> Seaside provides a layered set of abstractions over HTTP and HTML that let you build highly interactive web applications quickly, reusably and maintainably. </blockquote> Wow with all those promises, you have no excuse to deliver crappy webapps. I like those headlines have no meaning at all. Do not trust someone who is pretending that everything will be easy with his tool/framework. Except when the tool in question is Clojure or Smalltalk of course :) On API Consistency 2010-03-20T03:03:00+00:00 Interacting with a well design API is a pleasure. When an interface is consistent and works in the way I expect it to work I feel good. Gregory T. Brown wrote an excellent chapter</a> on this subject in his (now freely available) book 'Ruby Best Practices'. Something struck me in jQuery last week: map() and each()'s parameters. From jQuery's documentation</a>: .map( callback(index, domElement) ) .each( function(index, Element) ) jQuery.each( collection, callback(indexInArray, valueOfElement) ) jQuery.map( array, callback(elementOfArray, indexInArray) ) </code></pre> Ok, what's the deal? Look at the parameters of the callback of jQuery.map(). The order is different than all the others. Why? This kind of things drives me nuts.

TulipeMoutarde.be

Dependency injection in Axum handlers. A quick tour

How to botch an interview

Triathlon training ≈ Startup life

Our Tech Stack: Rust, Typescript, React & Swift

tl;dr</h1> Rust (actix-web, Diesel)</li> Swift (SwiftPM, swift-ast)</li> Typescript</li> React (Atlaskit, Redux)</li> AWS (Fargate, PostgreSQL RDS)</li>

The Tech Stack</h1> Bismuth has four main components:</p> Parsers for languages we support,</li> REST endpoints for API,</li> Workers that process the influx of code,</li>

Build mobile apps with Bazel. Part 2: iOS

Directory structure</h2> We will mirror the code organization we had for the android app:</p> AppA-iOS</li>

External CocoaPod library</h2> Many iOS apps load external libraries for common tasks. Carthage</a> and CocoaPods</a> are the most common tools to handle those dependencies. As an example, we will import the RxSwift</a> and RxCocoa libraries into our project. </p>

Build mobile apps with Bazel. Part 1

Multiple git repos</h3> It is common among developers and dev shops to have separate repos for different apps/libs. In our case, that gives 6 git repos:</p> AppA-iOS </li> AppA-Android</li> AppB-iOS</li> AppB-Android</li> Lib-iOS</li>

Lib-iOS and Lib-Android versioning</h3> A solution for the libs is to version them and add them as a dependency to our apps.</p>

About

Build a modern computer course on Coursera

Android Things

Android Google Study Jams Brussels Episode 2

Android Google Study Jams Brussels

Dependency injection with Dagger

Code</h2> The app has two modules, BingEndPointModule</code> and YahooEndPointModule</code>. Those are injected at runtime when you choose Bing and Yahoo in the UI.</p>

Closing</h2> That was short. Once again, you should clone u2020</a> and study its source code. It shows quite a lot in a condensed app.</p>

Pharo packages to know

iOS legacy code

Libraries</h3> CocoaPods</em> is the way to go to manage libraries.</p> The projects has Stig Brautaset's JSON tools copied into the project. The AWSiOsSDK also uses this json parser. Boum.</p>

Gradle Build Variants for your android project

Sample project</h2> The project is pretty simple but shows how you can define for each build variant:</p>

UILocalNotification alertBody

Scroll UITableView to currently selected UITextField

Pharo Sprint in Lille

Migrating from MS Works to LibreOffice - batch processing

Kill all the compiling!

Seaside wrapper for Filepicker.io

Deploying Pharo Application

Misc stuff about Voyage and MongoDB

Embedded Document with Voyage in MongoDB

MongoDB with Voyage in Pharo

Edit</h2> The issue with the collection name is caused by the following code:</p>

Vancouver Smalltalk Developer Group

Global package cache & stdin, stdout, stderr on Pharo

Limit hard dependencies in your code

Migrating to Pharo 1.4

No default browser</h2> Pharo 1.3 used to be shipped with OmniBrowser (OB). This is not the case anymore and the default browser is now the basic one. No advanced features, no refactoring, plain boring.</p>

Send email from Pharo with Postmark

Windows Phone 7

Legacy projects

Smalltalk & native UI

Smalltalk for the Rubyist

Metaprogramming, Object and Classes</h2> Okay, that one is tricky. What do you expect from meta-programming?</p> Adding methods on runtime? You are already in runtime.</li>

External CocoaPod library</h2>
Many iOS apps load external libraries for common tasks. Carthage</a> and CocoaPods</a> are the most common tools to handle those dependencies. As an example, we will import the RxSwift</a> and RxCocoa libraries into our project. </p>

Closing</h2>
That was short. Once again, you should clone u2020</a> and study its source code. It shows quite a lot in a condensed app.</p>

Libraries</h3>
CocoaPods</em> is the way to go to manage libraries.</p>
The projects has Stig Brautaset's JSON tools copied into the project. The AWSiOsSDK also uses this json parser. Boum.</p>