DEV Community: Noel Bautista

Ergodox-EZ Bundle Review

Noel Bautista — Sun, 19 Aug 2018 21:22:39 +0000

This review is a cross-post from my blog, in April 2017. My opinions haven't changed much, so here's my initial review.

After a month of waiting, my Ergodox split keyboard is finally here! At $295 for the new Ergodox Snow bundle with Gateron White switches, it's definitely not for the faint of heart. I decided to splurge as I spend a lot of time on my home workstation.

Packaging

The Ergodox shipped around 2-3 weeks after purchasing from ergodox-ez.com. Delivery took 2-3 days from Taiwan to Los Angeles, CA.

The UPS packaging was solid, as it protected the actual boxes from scratches. There were some minor dents on the boxes though.

I was disappointed at the lack of documentation that came with the Ergodox. Thankfully there's nothing to assemble, even the tents come attached!

I like that it's ready to go out of the box. I guess that justifies the lack of documentation!

Ergodox EZ Snow

But first, some photos!

The body of this ridiculously expensive keyboard feels reasonably rigid. Everything from the tents, the cables, and the rubber feet do not feel flimsy at all. Weight seems to be distributed well around the body. I don't feel any shaking or the keyboard sliding as I type.

The switches feel really nice. The Gateron White switches are supposedly really light, only requiring 35g of force to actuate. I chose them as Gateron Blue switches are too loud (otherwise they would have been my first choice) and I really like the feeling of light linear switches.

~~I'm not a fan of the tents.~~ The good about them is that they let the user tilt and angle the Ergodox in a lot of ways. The bad is that they sort of grind when you rotate them after tightening. After removing the tents, I noticed some metal powder coming out of the holes. Yikes! They hold the keyboard up nicely, as long as you don't put your entire weight on it.

Edit: After giving the tents another chance, I realize that they help a lot in making your hand placement more natural. I set the tents to lift the inner side of the keyboard and lower the outer side. See photos below.

The wrist rest (called Wing) is made of some rubbery feeling material. It's amazing because it's not too soft and is angled perfectly for the keyboard. It weighs heavier that it looks, but that's a good thing! The wrist rest's weight seems to help it stay in place. It feels REALLY good. That said, it is very solidly made with no cosmetic imperfections.

I highly recommend getting the bundle just for the wrist rests alone.

The default configs were pretty usable, but I found myself wanting more. Personally, I don't like the idea of keys sharing a modifier and a command (ex: Z and CTRL share the same key). It was pretty cool at first, as holding the key would activate the modifier (CTRL) and tapping activates the command (Z). However, it felt wrong and I like my modifiers at a familiar place away from other keys.

I spent about 2 hours remapping my keys using the configurator from the Ergodox-EZ website. It was time well spent as I feel great about my new configs.

Even after customizing, I still need practice with the Ergodox :P I still type really slow and make a ton of typos.

I like how the keycaps were marked to help the user identify how the keycaps go in. This was particularly helpful to me, as I have blank keycaps! The yellowing is from the sunset and bad photo angles.

I had one or two keycaps with weird excess plastic in the bottom. It's not noticeable while typing, but it would have been nice to not have.

I've always thought it was weird to have multiple stems for 1 switch. Not a big deal as the thumb cluster feels fantastic.

The cords are decent enough. They feel solid and rigid, but nothing crazy. They are a good length and should be good for the majority of users.

O-Rings for Extra Silence (Not Included in Bundle)

The Gateron White key switches are fairly silent (as any other linear switch). However, I wanted a quieter one! So I bought some 1.5mm thick o-rings from LPWL. All the rings I received were perfect and worked amazingly.

Here's a sound test of the Ergodox with (top row) and without the o-rings.

End

The Ergodox-Ez is awesome. It's solidly built and gasp ergonomic! It definitely takes a while to get used to, but once you do, it's hard to go back. At $295, it's hard to recommend to the casual user. Power users will feel right at home especially after customizing.

So if you have money.. give the Ergodox-Ez a chance, maybe even get the DIY Ergodox Infinity kit from Massdrop.

Writing Code That Makes Your Teammates Lives Easier

Noel Bautista — Wed, 28 Mar 2018 11:00:00 +0000

Working alone =/= working in a team. There might be things in your code now that might not be as easy to understand for other developers, including your future self. This is not about spending an hour automating a boring task. These tips are simple trivial changes. Simple enough that you wouldn’t have to rewire your brain or change your workflow 👍

PS: This is a cross-post from my blog.

tl;dr

Write good commit messages
Add comments to hacky implementations
Write self documenting code / variables / methods / classes instead of adding comments

PS: These tips have been helpful with me getting on and off with my side projects for long periods of time. I used to spend an hour or two getting back up to speed with my side projects. Now it only takes about 15 minutes!

PPS: Writing a good README with installation and usage guide helps :)

Write good commit messages

Commits are great are providing context about the project. In an ideal world, one could look into the history to understand why certain changes were made and how.

don’t:

- Refactor
- Fix bug
- Fix bug
- Cleanup
- Remove test [0]
- Add feature

Many things wrong here. What did the programmer refactor? What bug/s were fixed? What was cleaned up? What test was removed? What feature was worked on?

[0] When I inspected closely what test was removed, it turned out that it meant a ‘test’ word that somehow snuck in some css file as opposed to an actual test removed.

do:

- Refactor for loop to use .filter
- Handle edge cases
  - Don't empty cart when user logs out
  - Prevent crashes when more than 3 tabs open
- Remove redundant and unused code
- Implement feature X

This style of writing commits shares a living diary of the project. This makes it easy for anyone to find relevant changes just by looking at the logs (ex: git log). Chris Beams wrote a great piece on how to write commits.

Add comments to hacky implementations

What is bad about hacky code is that it is often undocumented and invites other developers to build on top of it. It becomes something that no one understands or knows about. Newer members of the team will try to avoid touching this code as much as possible and attempt to work around this code.

don’t:

my-class {
  ...
  flex-direction: column;
  ...
}

Our little hacky code could into something bigger and badder. It might not be obvious what it’s for and if it’s still relevant today. Working around it will eat up precious development time.

do:

my-class {
  ...
  flex-direction: column; // hack to center overflowing text in IE 10 https://stackoverflow.com/a/42302827
  ...
}

Months, or years down the line, your project might not even support IE 10 anymore. We can now remove this hack, and now we don’t have to worry about this hack’s other side effects.

Write self documenting code / variables / methods / classes instead of adding comments

Easier to read methods when accessed in a different class. Otherwise, user of API will have to read into the method/class to understand what it does. This is unnecessary and a waste of time!

dont:

void main() {
  play = true
  board = board()

  while (play) {
    input()
    play = win()
  }
}

do:

void game() {
  isPlaying = true
  initBoard()

  while (isPlaying) {
    getUserInput()
    playing = !hasWon()
  }
}

You can easily tell that the game() method initiates the game, prepares the game board, gets user input, and ends the game if the user has won.

The same applies to variable names.

dont:

// Updates the UI
void updateUI() { ..

// the data store
var store = ..

These comments add nothing to my understanding of what this variable is for. updateUI() -should- update the UI, etc.

do:

void updateUI() {
}

var store = Store()

Read this post for a more thorough reading on naming variables.

Modular and Dynamic UI for Android Phones and Tablets

Noel Bautista — Sun, 12 Mar 2017 00:00:00 +0000

This guide was originally posted last year at my blog. A year and a half later, the content still is very applicable.

A short Android developer’s guide on how to make responsive UI that makes both phone and tablet users happy. This is the companion blog post for my 10 minute presentation of the same title. There are code samples in the Example section of this post.

You can see the actual presentation here!

I want to highlight two things in this post: Modularity and Responsiveness. I think apps that keep both phone and tablet users in mind should have modular views/code and look good regardless of screen size.

Modular

Some views should be thought of individual modules: they should be able to stand on their own, or complement other views. Example: You’re building a screen that is somewhat similar in functionality for both phone and tablet, but the tablet version has an extra view.

You can do two things 1) create an activity that works for phone, another for tablet, or better 2) create fragments for these two views, use the same ‘modules’ for tablet version.

This way, you can avoid copy-pasting the same code for your views.

Responsive

A responsive app means the app can present itself well regardless of orientation or screen size. As a programmer, you don’t want to create different activities/fragments/views for different screen sizes. Instead, you want to write the same code and have Android do all the work for you.

Why It Makes Sense to Use Modular/Dynamic UI

Let’s look at the similarities and differences between phones and tablets.

People typically use phones in portrait mode. Portrait is somewhat limited in screen real estate, but it works well for lists.

Tablets gain a lot more screen space when used in landscape mode. A tablet in landscape showing the same layout as if it were in portrait mode looks awkward. There’s too much underutilized space! We could use that space to show more relevant information.

Phone users use one hand while navigating using their thumb, with the “sweet spots” located near the lower right corner of the screen. Tablet users vary. Sometimes they use two hands, one hand to hold the tablet, the other (forefinger) to navigate. Maybe they use one hand with the tablet laid flat on the table or docked at an angle. This tells us that locations of buttons, etc. on the phone may not work as well as on a tablet.

Phones and tablets share the same interaction paradigm. Users can swipe, tap, long press, etc. This is awesome, because this enables us to create a familiar experience for both users. We don’t have to “teach” them how to use a tablet.

tl;dr - Users can perform the same actions, but you can show more data with a tablet in landscape mode. You might need to reposition stuff to help the user navigate the app better.

So.. now we’re motivated to write a responsive app that works well on both phone and tablet! How do we do this on Android?

Android resources can be specified using qualifiers. Android loads the corresponding .xml resource based on declared qualifiers. Qualifiers are simple to get into, but could get quite complicated depending on usage.

To simplify this post, let’s stick to using the smallest width qualifier (specifically, 600dp). This ensures that we will use a different layout whenever Android detects that there is at least 600dp available for either length or width of the screen.

Wait, why not check if the device is used horizontally (landscape mode)?

We care about showing the user more data / repositioning views when there is enough screen the app could use. Using land (landscape) as a qualifier only checks if the device is used horizontally. What if the device is actually 4:3, and landscape mode doesn’t have as much screen space as we thought?

Consider the gif below. This is a tablet in landscape mode. If we used land as the qualifier for the “bigger” layout, the app would have been only displayed in the “bigger” layout. Instead, we let Android use the “smaller” layout if necessary by using the w600dp-land qualifier.

w600dp-land lets Android choose the bigger layout when there is at least 600dp width and if the device is in landscape. The bigger layout is commonly referred to as the Master-Detail Pattern.

Example

Let’s look at this example from one of the open source projects I follow, Standard Notes. It has a generic user interface, making it easy for us to pick it apart.

Here’s a regular RecyclerView with a Floating Action Button (FAB). Let’s call this screen the NotesListFragment. Upon clicking the FAB, it takes the user to the CreateNotesFragment screen. Let’s refer to the “meat” of the window (white area w/ text below the toolbar) as R.id.main_content.

You can see there’s nothing crazy here. I am simply using FragmentTransaction to add whatever is on R.id.main_content with our new CreateNotesFragment. I also used addToBackStack() so that when the user hits the back button, the user is brought back to the NotesListFragment.

supportFragmentManager
   .beginTransaction()
   .add(R.id.note_list_container, noteFragment, TAG_NOTE_FRAGMENT)
   .addToBackStack(null)
   .commit()

Let’s call the Activity handling these Fragments as MainActivity, and it’s corresponding layout activity_main.xml. activity_main.xml contains:

<Drawer layout + toolbar stuff..>
    <include layout="@layout/main_container" />
</closing tags>

And under layout/main_container.xml:

<FrameLayout
    android:id="@+id/note_list_container"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    app:layout_behavior="@string/appbar_scrolling_view_behavior"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

So far, so good!

What about tablet/large landscape layouts? We can use the Master-Detail pattern for this!

I created a new layout under the w600dp-land folder. Recall earlier that Android will load this layout when the w600dp-land criteria is met. All this new layout contains is:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:orientation="horizontal"
    android:showDividers="middle"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <FrameLayout
        android:id="@+id/note_list_container"
        app:layout_behavior="@string/appbar_scrolling_view_behavior"
        android:layout_weight="1"
        android:layout_width="0dp"
        android:layout_height="match_parent" />

    <FrameLayout
        android:id="@+id/note_container"
        android:layout_marginTop="?android:attr/actionBarSize"
        android:layout_weight="3"
        android:layout_width="0dp"
        android:layout_height="match_parent" />

</LinearLayout>

Again, nothing too crazy here. I am adding the NotesListFragment to R.id.note_list_container, and replacing CreateNotesFragment to R.id.note_container. (This is a simplified example. In the app I am doing a few checks for savedInstanceState, etc)

supportFragmentManager
    .beginTransaction()
    .add(R.id.note_list_container, noteListFragment, TAG_NOTE_LIST_FRAGMENT)
    .add(R.id.note_container, noteFragment, TAG_NOTE_FRAGMENT)
    .commit()

Phew! That was a lot. However, there’s more :D

In the screenshots, the FAB in landscape disappears and turns into a MenuItem, with the text “New Note”. Thankfully, qualifiers work on menu layouts as well! In this example, the NotesListFragment layout handles the FAB.

Let’s refer to the NotesListFragment regular menu layout as menu_list.xml. This “menu” layout is left empty for our purposes.

but in menu-w600dp-land..

<menu xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <item
        android:id="@+id/new_note"
        android:title="@string/new_note"
        android:orderInCategory="1"
        app:showAsAction="ifRoom" />
</menu>

We’re adding a new menu item with the id new_note whenever the qualifier w600dp-land is met.

How will NotesListFragment know when New Note is clicked? There’s quite a bit of boilerplate, but it’s relatively short. We want to tell MainActivity that NotesListFragment has its own menu items, and we want to display it. NotesListFragment will also handle click events for New Notes.

Excuse my kotlin.

override fun onCreateView(-stuff-): View? {
    val view = inflater.inflate(R.layout.frag_note_list, container, false)
    setHasOptionsMenu(true) // tell `MainActivity` to display this fragment's menu  
    return view
}

override fun onCreateOptionsMenu(menu: Menu, inflater: MenuInflater) {
    inflater.inflate(R.menu.note_list, menu) // inflate this menu layout
    super.onCreateOptionsMenu(menu, inflater)
}

override fun onOptionsItemSelected(item: MenuItem?): Boolean {
    when (item?.itemId) {
         R.id.new_note -> startNewNote(selectedTagId) // handle click events for "New Notes'
    }
    return super.onOptionsItemSelected(item)
}

That’s it for this example!