DEV Community: Sami Pietikäinen

Don't over-engineer!

Sami Pietikäinen — Thu, 07 Feb 2019 17:31:55 +0000

Most if not all programmers nowadays are familiar with the concept of clean code. In short, the clean code principle means a development style that focuses on code that is easy to write, understand and maintain. Yet, it seems that often these same principles are not applied to the overall design.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

Still, even if a code base has clear naming practices, meaningful comments and the code in function-level is understandable and clean, it is still possible that the overall design is hard to comprehend and the project is hard to maintain. This is often because the same clean coding methodology that is applied to code in small is not applied to the overall design. The design is over-engineered.

Sometimes the code base looks as if the author read "the Gang of Four" design pattern book and tried to apply every single one of them in a single code base. There are just facades, decorators, adapters, observers and other design patterns on top of one another and the overall design is nearly impossible to grasp. Other times it seems that the author had an impulse to reinvent every wheel there is. Own containers. Own locking primitives. Own algorithms. Everything written from scratch.

Overly complex, over-engineered code can be as hard to understand and maintain as badly written spaghetti code. Of course, sometimes projects really are complex and require abstractions and architecture that is challenging to understand. There also certainly are situations where implementing your own algorithms or containers is the right thing to do. The important thing is that there should be a clear reason why that additional complexity is necessary. The design should never be complex just for the sake of complexity. In fact, contrived complexity, forced use of overcomplicated design when simple would suffice, is one of the common code smells described by Martin Fowler.

Projects may end up overly complex for a number of reasons. The design might be clean and simple in the beginning, but become muddy and complex when new features and other changes that not quite fit the architecture are glued into it without refactoring. Other projects might be too complex from the get-go when the design tries to accommodate all imaginable changes that might happen in the future.

Thing is, designing a good solid architecture is not easy. In real-world projects requirements change along the way and new features are introduced that were not known in the beginning. Also when the project matures, other fixes, tweaks and updates are applied along the way. On top of that, project schedule often adds pressure to get things done quickly. The design should be flexible enough to allow all these changes with reasonable effort while still being as simple as reasonably possible. And even without all these external changes it is hard the get the design right on the first try. It usually takes some iterations and refinements to converge to the final design

Unfortunately there is no silver bullet that always gives an optimal architecture. But applying the same clean coding principles that work on function and class level to architecture is a good way to avoid muddy and over-engineered design. Probably the most important advice is to keep things simple. Add configurations and use design patterns only when really needed. Create abstractions only when they contribute positively to the design by removing duplication or decoupling modules for instance. Don't try to predict future. Design the system using requirements that are actually known today.

When the future does come and the design needs to adapt, it is important that the system is easy to change. Often new features require refactoring the existing design or otherwise they are just glued in which decays the architecture. Soon even simple changes can break the system unexpectedly from multiple places and subtle bugs are introduced. Changes start to take longer and longer to implement because the design is too fragile.

The key to make the design easy to change is to make it easy to test. When the functionality can be verified easily and automatically, developers can make refactorings without being scared of breaking things. When the system is easy to test, it is easier to refactor continuously and thus keep both code in small as well as the larger design clean. Small imperfections and problems tend to grow so deal with them immediately.

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

Andy Hunt, The Pragmatic Programmer

Don't live with broken windows. Make sure both the code and the larger architecture stays simple and clean. Refactor continuously to accommodate changes, and add abstraction and complexity only when it is justifiable and contributes positively to the design. Don't over-engineer.

Originally posted on my personal blog

Why junior devs should review seniors' commits

Sami Pietikäinen — Sun, 08 Apr 2018 13:45:19 +0000

Code reviews are a great practise to find mistakes, potential bugs and other issues overlooked by the code author. Reviewing improves the overall code quality, but it is also a great way to share knowledge and information. Junior developers' commits should certainly be reviewed by more senior developers, but juniors should also be the reviewers. Here's why.

In every project there are things that need familiarization when a developer (junior or not) joins the team. These can include for instance code and project organization, testing, build, deployment and the general way of working in the project. Especially in large projects, understanding the existing architecture and design decisions as well as the rationale behind these decisions can be a major challenge for a new developer.

Both the technical aspects and the way of working can usually be found from the project documentation. Nevertheless, implementing new features or fixing bugs in an unfamiliar code base is still challenging. What would be a better way to learn than following the example of more experienced developers in the same project?

What would be a better way to learn than following the example of more experienced developers in the same project?

Having young developer go through commits of experienced developers by reviewing is a great learning experience for the reviewer. Not only does it give a great reference for design and architectural decisions as well as coding and style practices, but it also shows how to apply these in the actual project in which the developer is working on. For the reviewee, it does not hurt to have an extra set of eyes looking at the code even though the reviewer is not so experienced. In fact, someone who is not so familiar with the project most likely looks at it from a fresh perspective.

A lot of the benefits from this kind of review goes to the junior developer. However, there are also benefits for the project. Obviously the developer can familiarize quicker, but the reviews also give a wider view to the project than what would be directly necessary for the task at hand. Chances are that the now new developer will at some point maintain the project, so having a wider perspective from the get go is invaluable.

So far the discussion has been solely technical. Yet, the review practices can also have a social effect. When a new developer is asked to review commits of already established members, it shows that they are accepted as a member of the team and their input and opinions are valued. As always, successful review practices require healthy working environment. Everyone should be able to both give and receive feedback without taking the comments personally. To reinforce this atmosphere it is good to have everyone from juniors to seniors to be both reviewers and reviewees.

These same practices can also be applied across teams and across people with different competences. Why not have embedded developers review some GUI code or backend developers some front-end changes. Just because something is beyond someones' main competence area, does not mean they would be unable to spot mistakes or give feedback (of course some more subtle mistakes that relate to a specific library or language would still need reviewer with strong competence in that area).

So let's make the most of code reviews and have everyone from juniors to seniors take part.

Implementing REST client with Rust: an introduction to traits and generics

Sami Pietikäinen — Wed, 27 Dec 2017 09:21:00 +0000

After reading the Rust book and writing about my initial experiences, I wanted a small practical project to familiarize myself with the language. So, I decided to write a REST client library. This post shows, step-by-step, how my initial design was refactored to be more robust and easy-to-use. Traits and generics are key concepts in these refactorings. The intent is not to cover the internals of the library in detail and also the basic syntax of traits and generics is not covered here. The Rust Book chapter 10 is an excellent resource for the latter.

Restson

The library I implemented is called Restson and it is a client library for JSON encoded REST APIs. The main idea is to provide easy-to-use interface for API requests and also handle URL parsing as well as serialization and deserialization from Rust structs automatically. The library is implemented using Hyper, which is the de-factor HTTP library for Rust.

The Restson library is available in GitHub and in crates.io.

Design iterations

When I started writing the library I was new to Rust (I still am) and I had also never used Hyper before. So I did not end up with elegant design right away. Though, usually you don't end up with the final design right away even if you are familiar with the language. At least for me it usually takes some iterations and refactoring to improve and refine the initial ideas and structures.

Lets look at how the GET interface signature looked initially:

pub fn get(&mut self, url: String) -> Result<String, Error>

So the function took the REST endpoint URL as a parameter, performed the GET request with Hyper library and then returned the request body as a string. From functionality point-of-view the function above is not wrong because it does get the job done. However, it is not ideal for the library user and there are also multiple disadvantages with this design.

The whole URL needs to be provided every time the interface is used:
- URL literals scattered in the code
- Changing the base URL requires modifying all the API calls
Client caller needs to handle URL parsing (which adds boilerplate and is error prone)
Client caller needs to manually deserialize the returned JSON in GET and serialize data to JSON in POST.

Lets look at how these disadvantages can be fixed by improving the library interface.

Automatic (de)serialization

Lets put the URL parsing aside for now, and look at the return value of the function first. For simple use cases it might be ok to just manipulate the JSON directly, but it is often better to deserialize it to struct. This allows the compiler to do proper type checks and also reduces dependencies to the exact JSON format. For instance, if some field name changes, only the (de)serialization code needs to be updated instead of all the places where the data is used.

To be able to return deserialized data, the get-function needs to know the type in which the JSON is deserialized to. However, these types are defined by the library user and cannot be fixed in the library code. This can be solved by making get a generic function:

pub fn get<T>(&mut self, url: String) -> Result<T, Error> where
    T: serde::de::DeserializeOwned

Generic type T is introduced and instead of returning Result<String, Error> the function now returns Result<T, Error>. Now the function can return different user defined types that are deserialized from the JSON returned by the server. In Rust, type inference also makes generics convenient to use:

let data: MyType = client.get("url").unwrap();

In the code above, the compiler is able to figure out that generic type T in get must be MyType because the return value is assigned to variable of that type (return value of unwrap to be exact). The generic type could also be explicitly annotated but it is unnecessary here. The call above is equivalent with the example below.

let data = client.get::<MyType>("url").unwrap();

You might be wondering what is the where T: serde::de::DeserializeOwned part for. Well, the generic type Tcannot be any type. The get-function can only accept types that implement deserialization interface. In Restson library, the deserialization is implemented using Serde library, so type T needs to implement DeserializeOwnedtrait. This way the implementation of get can call serde_json::from_str function for that type.

The where clause sets a trait bound which makes sure that if T does not implement DeserializeOwned and thus does not have serde_json::from_str function available, the build won't pass. For the library user, implementing this trait is easy thanks to macros provided by Serde.

#[derive(Deserialize)]
struct MyType {
    field1: String,
    field2: String,
}

By using a generic type for the return value, the library is now able to automatically deserialize the data to user defined types. Relatively minor change on the library that makes the interface more convenient to use.

URL handling

First obvious improvement to the URL handling is to give the base URL when the client instance is created. Then the individual API functions like get would only take the REST path as a parameter.

This is already better, but still error prone. It would still be easy to use wrong type of return value with an API path. This would mean that deserialization would always fail, and the error would not be caught during compilation. Furthermore, there would still be path string literals scattered in the code.

One approach to solve this would be to associate the API path with the type that is used with the library. That is, each type that is used in REST requests would be able to return the corresponding API path. This is accomplished by defining a trait for the REST path.

pub trait RestPath {
    fn get_path() -> String;
}

pub fn get<T>(&mut self) -> Result<T, Error> where
    T: serde::de::DeserializeOwned + RestPath

Now, each type that is used as the return type T, must implement both DeserializedOwned and RestPath traits. This is also enforced by the compiler, and if the traits have not been implemented the build will fail. The URL parameter can be removed from get altogether because the implementation can call T::get_path() to get the correct path and the base URL is provided when the client is instantiated. The trait implementation simply needs to return the correct path string:

impl RestPath for MyType {
    fn get_path() -> String { String::from("apipath") }
}

Now the API path is only defined once and the interface can be used without even knowing what the actual path string is:

let data: MyType = client.get().unwrap();

There is still one major weakness in this design. For instance, a path like api/devices/<ID>/status would be difficult to implement because it contains a parameter that should be easily changeable. However, the current get_path does not take any parameters.

Parametrized paths

To be able to return parametrized API paths, the get_path functions should take a parameter that is used to format the path string. For instance:

impl RestPath for MyType {
    fn get_path(id: u32) -> String { format!("api/devices/{}/status", id) }
}

This parameter would also need to be forwarded from the interface functions such as get. The problem is, however, that this is library code and cannot know what types the library user would like to use as path parameters. One way to dodge this problem would be to pass, for instance, a vector of strings. Although this would work, it is not optimal. For one, it would require unnecessary string conversion code for the library user and also make error checking in the trait implementation harder. Better alternative is to make RestPath trait generic.

pub trait RestPath<U> {
    fn get_path(par: U) -> Result<String, Error>;
}

Now the library user can use whatever parameter type to implement the trait. The return value is also changed to Result<String, Error> so that the trait implementation can indicate errors with the provided parameters. These changes also require changes to get interface to pass the parameters.

pub fn get<U, T>(&mut self, param: U) -> Result<T, Error> where
    T: serde::de::DeserializeOwned + RestPath<U>

Another generic parameter U is introduced to the interface which is used in the trait bound RestPath<U>, and also taken in as param. When the library implementation calls get_path function, the parameter is passed to it T::get_path(params). If a RestPath implementation for type T with correct parameter type is not found, the compiler produces an error. The interface now looks pretty complex but it is actually pretty simple to use.

First the RestPath is implemented for user type:

impl RestPath<u32> for MyType {
    fn get_path(id: u32) -> Result<String,Error> { 
        Ok(format!("api/devices/{}/status", id)) 
    }
}

Then the path parameter is simply given to the interface function which passes it to get_path.

// calls api/devices/1234/status and deserializes
// returned JSON to data variable
let data: MyType = client.get(1234).unwrap();

The RestPath trait can also be implemented multiple times for the same type with different generic parameters. It is also possible to provide multiple path parameters by using, for instance, a tuple.

Conclusions

These refactorings improved the initial design which, although working, was not very convenient for the library user. It was also prone to errors that could not easily be detected during compilation. By using a combination of generics and traits the interface was kept simple to use but still a lot of common functionality (such as serialization) was encapsulated inside the library. User types were also allowed with the library which enables more error checking by the compiler (compared to passing things as, for instance, strings).

All in all the traits and generics are powerful tools to have especially when writing library, utility or other reusable code.

My experiences learning Rust

Sami Pietikäinen — Thu, 21 Sep 2017 17:30:59 +0000

Originally posted on my personal blog.

Having seen a lot of positive buzz around the Rust language, I decided to look into it myself aswell. So, past couple of weeks I have been reading the second edition of The Rust Programming Language book which is an introductory to the language. This blog post is a round-up of my first impressions about the language and its features, and it also serves as a quick intro for others interested in it. In my day job I work mostly with C and C++ so those are my main reference points when learning a new language.

Overview

In the first chapter of the book the main idea of Rust is coined as follows.

Rust is a programming language that’s focused on safety, speed, and concurrency. Its design lets you create programs that have the performance and control of a low-level language, but with the powerful abstractions of a high-level language.

Coming from the embedded world I especially like the fact that Rust has a strong focus on safety, performance and concurrency. Many other modern languages have chosen an approach with garbage collection and many also require a runtime which can make them unsuitable for low-level programming. This is probably one of the main reasons that languages such as C and C++ are still very widely used.

Rust is a compiled language and the binaries are compiled directly to target architecture. Rust also does the safety checks during compilation so the added safety does not have runtime performance penalty, which makes it quite unique.

Borrow-checker

Ownership is a key concept in Rust. Each value has a variable that is owner of that data, and there can only be one owner at a time. If the value is moved to a new variable, the ownership is transferred and the old variable becomes invalid. Values can also be borrowed using references but there can only be one mutable reference at a time. These rules are enforced at compile time by a borrow checker.

In contrast, C/C++ do not have a concept of ownership similar to Rust’s. For instance, in C++ there can be multiple pointers and references to same data simultaneously, and it is the programmer’s responsibility to make sure that there are, for instance, no data races. At first it might feel that the borrow checker “just get’s in the way” because it produces a lot of compiler errors (at least before you get used to the ownership concept), but in the end it provides valuable safe-guards against many common issues.

No Exceptions

Developers who are familiar with languages like C++, Python and Java should also be familiar with exceptions as an error handling mechanism. When an error occurs, an exception is thrown and the call stack is unwind until the exception is caught. If the exception is not caught at all, the program is terminated. This scheme allows some parts of the code, for instance libraries, to easily let the application logic to handle errors in a meaningful way. One drawback however, especially in C++, is that it is hard to tell which exceptions can be thrown and also the error handling code can be far away from the part that triggered the error.

The error handling approach in Rust is not to use exceptions. Instead, Rust has two different mechanisms for error handling. If the error is unrecoverable, the program will panic (i.e. terminate). Alternatively, for recoverable errors Result<T,E> type is used. With this approach the compiler can enforce that the error variant is always handled when the return value is obtained from the Result. This is also much more robust than encoding the failure information to the returned value (e.g. returning -1). Moreover, Rust also provides syntax to easily propagate errors from functions with ? operator.

fn file_len() -> Result<u64, io::Error> {
    Ok(File::open("test.txt")?.metadata()?.len())
}

In the example above, if either open or metadata call fails, the returned error is automatically propagated without the need to explicitly read and return it. This removes unnecessary boilerplate code and makes the resulting code simpler and cleaner.

Enums On Steroids

I have strong C/C++ background so for me enumerations are just a collection of explicitly named constants that use integral type as underlying type. In Rust enums are much more than that, and they are better described as a type that represents one or many variants. These variants can also include data, and what’s more each variant can also have different data.

This makes the enum type suitable not only to enumerate the possible variants but also to model their data into the same type. Examples can be found from the Rust by example website.

It's a Match!

Another cool feature in Rust are patterns. Patterns and pattern matching are used in many places but probably the most powerful is the match operator. It can be thought of as, well, switch-case on steroids. Instead of matching simple values, it is possible to have complex patterns and have additional match guards as well. Also, the compiler enforces that all enum variants are always handled. Here’s an example:

let p = (4,3,2,1);

match p {
    (2, ..)             => println!("first is 2"),
    (a, .., b) if a > 2 => println!("first {}, last {}", a, b),
    _                   => println!("default...")
}

The first case (called a match arm in Rust) matches if the first field in the tuple is 2. The second arm captures first and last field (so that they can be used in the match body) and matches if the first field is larger than 2. Finally the third arm has a wildcard and will mach all remaining cases. This also satisfies the requirement that all cases need to be handled. This is just a simple example and there is a whole chapter dedicated for patterns in the Rust book. Basically, the very flexible enums combined with pattern matching provides a very expressive way to model and manipulate data.

Type Inference And Coercions

Rust is a statically typed language which means that the compiler must know all the types during compilation. In other statically typed languages like C this means that the programmer must explicitly tell what types variables, parameters and return values are. In Rust a technique called type inference is used to deduce the types. So, even though the language is statically typed, most of the time programmer does not need to write the type explicitly. The compiler is able to figure it out from the context.

// create a empty vector without annotating the type
let mut a = Vec::new();
// here the compiler is able to see that it is Vec<String>
a.push(String::from("test"));

Rust also uses deref coercion which is easily demonstrated with a simple example.

use std::sync::Arc;

fn func(s: &String) {
    println!("{}", s);
}

fn main() {
    let s = Arc::new(String::from("test"));
    /* access value in Arc with * and then take reference with & */
    func(&*s);
    /* Compiler does deref coercion and translates &s automatically to &*s */
    func(&s); 
}

First atomically reference counted String object is created (String wrapped in Arc). Then a function that takes a reference to string is called with this object. First the object inside Arc is explicitly accessed with * operator. Deref coercion allows us to just type &s because it is clear that we intend to use the value inside the Arc. Overall, the coercions and inference allow to simplify the code in situations where the compiler can figure out proper types without explicit annotations. Modern C++ has auto keyword, but Rust takes this concept further.

Zero-cost Abstractions

One of the selling points of Rust are zero-cost abstractions. In practice this means an ability to use high-level concepts such as closures and iterator adapters without any performance costs. Also, when using these high level aspects the produced code is as fast or faster than hand coded implementation.

Here's an example that shows functional programming in Rust:

use std::collections::HashMap;

fn main()
{
    let mut dict = HashMap::<char, usize>::new();

    String::from("test string").chars().for_each(|x| {
        let item = dict.entry(x).or_insert(0);
        *item = *item + 1;
    });

    println!("{:?}", dict);
}

The code calculates occurences of characters from input string, and generates HashMap with char-count pairs. The example above outputs:

{'t': 3, 'e': 1, 's': 2, ' ': 1, 'r': 1, 'i': 1, 'g': 1, 'n': 1}

There's No Null

One interesting idea in Rust is that the language does not have a concept of null. At first thought this might seem very strange since we’re all so used to it, but it does remove a myriad of common bugs altogether. In other languages like C/C++ pointers have to be explicitly checked for null or the application will crash and burn if the null object is dereferenced.

Usually null value is used to indicate that some resource is not valid, and this information is indicated by a special null value. The problem is that the null condition needs to be manually checked which is error prone. The concept of something not necessarily being valid is still needed in Rust. It is just implemented differently.

Instead of indicating the invalid state of an object by special value, Rust implements this by wrapping the actual object in Option<T> or Result<T,E> type. This way when the concrete type is accessed the compiler will enforce that also the fail case is handled or the code won’t compile.

Fearless Concurrency

One of the big goals, and also one of the chapters in the Rust Book, is fearless concurrency. As one would expect, Rust provides the familiar primitives like threads, mutexes and also channels for message passing. However, the lifetime model and ownership rules makes working with concurrency much safer than in many other languages.

Rust is, for instance, able to detect data races between threads. That is, when multiple threads try to modify same data without proper mutual exclusion. The ownership system and the way mutexes are implemented also guarantees that locks are always acquired and released. Also the trait system is used to “mark” types that are thread-safe which means that the program will not compile if unsafe methods are used in a threaded context.

Convention Over Configuration

Rust uses a convention over configuration design paradigm which aims to decrease the number of decisions developers need to make. This paradigm is used heavily on code and test organization. Code modules, source files, unit tests and integrations tests are organized in a certain way and the compiler is able to find these items without explicit configuration.

One of the main benefits of this paradigm, besides the reduced configuration, is that different projects are organized in a similar manner which makes navigating other project’s sources easier. This is certainly not the case with C++.

Useful Compiler Error Messages

If you have ever made a mistake with C++ templates (for instance the STL), you probably know what useful error message does not look like. You’ll most likely get couple of screenfuls of incomprehensible text. The error messages can be cryptic even for the most simplest of errors.

My experience with Rust so far is that the compiler errors are really helpful and often point out the exact error and even suggest the fix. For instance, if the file_len example earlier had an extra ; in the Ok(File::open(“test.txt”)?.metadata()?.len()); line, the compiler error is:

error[E0308]: mismatched types
 --> src/main.rs:5:41
  |
5 |   fn file_len() -> Result<u64, io::Error> {
  |  _________________________________________^
6 | |     Ok(File::open("test.txt")?.metadata()?.len());
  | |                                                  - help: consider removing this semicolon
7 | | }
  | |_^ expected enum `std::result::Result`, found ()
  |
  = note: expected type `std::result::Result<u64, std::io::Error>`
             found type `()

“Consider removing this semicolon” and it is even pointed out in the code. Pretty useful. This is important because especially in the beginning you are likely to get errors often (at least I did) due to the many checks Rust does. This of course is a good thing because the checks point out potential bugs in the code. But it certainly helps a lot when the compiler points you out to right direction.

Strict Types And Casts

In C and C++ the compiler converts numeric types automatically. So a C/C++ developer would expect that assigning a uint8 to uint32 should just work.

let a: i8 = 5;
let b: i32 = a;

Well, Rust is more strict about types and the code above would produce an error. The programmer must explicitly cast the value to correct type let b: i32 = a as i32;.

Object-Oriented Or Not?

Inheritance sets Rust apart from many common high-level languages. That is because Rust does not have it even though it does have other object-oriented features like encapsulation. On the other hand, Rust has a feature called traits to describe a common behavior same way as interfaces are used in other languages. Also trait objects can be used in a same way as polymorphic types in languages with inheritance.

Whether Rust is categorized as object-oriented depends on the definition. Object-oriented patterns can still be implemented in Rust, but probably the approach needs to be a bit different from the “textbook” implementation. There is a complete chapter dedicated to this discussion in the Rust Book.

Conclusions

There is so much more that could be written about Rust. For instance, support for unit and integration testing or the cargo tool and crates.io. Though, the main idea here was to briefly introduce some aspects about the language and standard library that I find especially interesting. If this got you interested, I would really recommend the Rust Book. It’s easy to follow, covers the language comprehensively and best of all is completely free.

From what I have learned so far, Rust seems to address many of the common challenges in programming. Best of all, these additional checks and guarantees are done during compilation so they do not have a run-time penalty. The language is also compiled directly to machine code which makes it suitable for embedded targets (where garbage collection or runtimes would be unsuitable). As my first project I started to work on REST client with automatic serialization and deserialization. Overall my first impression is that a lot has been done right in this language. Can’t wait to dive into deeper!

Easily auto-squash changes to previous commit

Sami Pietikäinen — Wed, 12 Jul 2017 17:49:07 +0000

After committing, I always like to go through the diff before pushing the changes upstream. Just to make sure that everything is as it should be. Well, quite often I still spot some typos, commented out code that I was supposed to remove or some other minor things that need to be fixed. So I ended up running the same exact commands time and time again. First new commit for the fixes and then interactive rebase to squash the changes to the previous commit. Perfect opportunity to make an alias to save those precious keystrokes.

fixlast = !git commit -a --fixup=HEAD && GIT_EDITOR=true git rebase -i --autosquash HEAD~2

You can add the aliases to, for instance, your ~/.gitconfig file. With this alias you can easily autosquash changes to the previous commit by running git fixlast.

So let's break it down quickly. To easily run multiple commands I've used ! to run shell commands instead of only git sub-commands. The first part takes all changes and creates a fixup commit for the previous commit, HEAD. The fixup argument adds fixup! prefix to the commit message which will be recognized by the autosquash later.

The second part starts interactive rebase and tells git to process all fixup and squash commits (--autosquash argument). The HEAD~2 takes two topmost commits to the rebase.

Normally, the interactive rebase opens an editor, but in this case we really just want to accept the autosquash without any manual selections. To do so GIT_EDITOR environment variable is set to true (i.e. /bin/true application). So when git wants to open the rebase editor, it just receives success return code immediately and carries on with the rebase. That's all there is to it.

Edit: Just realized that the solution above is bit overly complicated. You could accomplish the same with --amend commit flag. Still, using the GIT_EDITOR environment variable can be used to avoid the amend editor pop up.

This was also posted on my blog. Check it out if you're interested.