
Wellness or well-being is the state of being comfortable, healthy, or happy. This state of well-being can exist in one's life as a whole, as well as in each arena of a person's life, eg. they have a state of well-being in their social life, their home life, their emotional life, and their work life as say, a software developer.

In many cases, there can be very strong correlations between a person's level of well-being and personal satisfaction of their tasks during their working hours and their productive output. Naturally, we want both personal satisfaction and output to be high, and so we would do well to find ways to improve both, and reap the benefits.

<figure>
  <img src="/assets/blog/2019-05-15-developer-wellness/matcha.jpg" style="display: block; max-width: 100%;" alt="Matcha latte and laptop">
  <figcaption>Photo by Jason Leung on Unsplash</figcaption>
</figure>

## How Developer Wellness Differs From General Personal Wellness

As developer wellness is a subset of personal wellness, it centers especially around the health and robustness of your presence in your job and career. However, the two cannot be completely separated as each feeds the other.

They are essentially the same thing, perhaps with different scopes of interest. How you do one thing is most likely how you do everything else in your life. Although we can talk about the points of well-being in a developer capacity, they correlate strongly to very similar points in your life as a whole.

## What A Healthy State of Developer Wellness Could Look Like

For each person who works as a software developer, the doings of a healthy state of well-being will appear to be different, but will most likely contain most of the same themes and even very similar practices.

The positive consequences of maintaining a healthy state of well-being as a developer are many, and include benefits at work as well as outside work.

### At Work

- healthier relationships with coworkers, managers, and clients.
- more enjoyment of the mental challenges inherent in a developer role.
- a healthy workspace setup, conducive to minimized distractions both on-desk and online.
- an openness to learning and practicing effective techniques to engage more fully on the task at hand and combat mental fuzziness while problem solving.
- a healthier relationship with writing code, and receiving criticism and feedback from others in a healthy and robust way.
- an increased ability to positively influence others helping create an overall healthier and more resilient team of developers, and a firm and solid base for a company or development department to thrive.

### Outside of Work

- an increased enjoyment of non-code related activities.
- an increased ability to "turn off" the work mind, and "tune in" to the moment.
- an increased ability to bring the same level of mental engagement to personal pursuits and hobbies - for example practicing a martial art, or a foreign language, or a musical instrument.
- an increased enjoyment of deliberate omission of screens from certain times and activities in your day to day life.
- an increased ability to be fully engaged with social relationships outside of work and/or within a home, or other social environments.

### The Benefits of a Pursuit of Personal Wellness, as a Developer

As developers, we often take pride in our strong powers of reason and logic, and rightfully so! It is the material of our craft! You can make some amazing improvements and significant changes in your life and career if you can approach the issues you see with a detached and experimental mindset, and come up with possible solutions to the pain points that you find, building on what works in small increments.

## Habits and Practices That Foster Developer Wellness

There are three things that cross into all subsets of wellness and cannot be omitted in the pursuit of wellness within any scopes: **DIET**, **EXERCISE**, and **SLEEP**.

### Diet

There are a myriad of considerations with diet, and for this reason I will leave you only with very general guidelines, if possible:

- Stay well hydrated. Make sure to drink enough water for your body.
- Try to eat more whole foods, and less heavily processed foods.
- Snacks are fine, but be mindful of those times when you're filling a dull moment with excessive sugar/salt/coffee consumption.

### Exercise

Exercise is often looked down upon, as a chore that _should_ be done, but many times isn't. This is not a healthy attitude, and must be addressed.

- If you feel that you are at level 0 in exercise in your life, all that that means is that you can only go up from here. Instead of a snack break, how about an mid-afternoon exercise break? Even a short brisk walk around a few city blocks counts. Afterwards, you will feel more alert and ready to tackle the rest of the afternoon!
- If you stick to some kind of exercise program already and/or go the the gym or participate in some other physical activity, keep it up!
- At the very least, get up from your desk and stretch in whatever ways feel best for your body. Long periods of physical inactivity do not feel great for the body, and are not especially good for you, either.

### Sleep

Sleep is another big piece of the puzzle that many want to downplay. However, this is not a good idea. The effects of not getting enough sleep will creep up on you. Different people require different amounts of sleep, but some general guidelines can still be mentioned:

- Less than 5 hours per day on average in a week is usually not enough sleep.
- There are also upper limits on sleep as well, but some people claim to need up to 10 hours per night.
- If after waking up, you feel generally good and ready to handle the day, that's probably a good number of hours for you.
- Make sure to prepare for sleep before getting into bed: maybe stretch, or read, or whatever thing helps you to wind down and get into a good headspace to let go of the day's events so that you can sleep as easily as possible.

### Questions to Ask Yourself About Wellness

Let's say that you have reached a point where you feel there are pain points that you want to address, or adjustments that you want to make in order to better your time spent at work in various ways mentioned above. Great! Now, where do you start? You can start by asking yourself a few questions as a jump off point:

- What is your personal definition of developer wellness?
- What would it feel like to enjoy a high level of wellness as a developer? Does it seem possible?

  - How can you bring the real and the imagined into closer alignment?

- In what ways would this increase your enjoyment of your experiences, coding and otherwise?

  - If your enjoyment is less than desired, is your effectiveness an addressable issue?
  - What can you get better at (and how?) in order to be more effective, and gain more enjoyment from something that currently pains you?

- What other things can you learn to enjoy and become more effective at?
- How can you model what you've already done in this respect in other areas of your life?

- In your opinion, which social aspects of your job contribute to your perceived wellness?

  - more time collaborating with others? High level collab or lower level collab?
  - more time alone?

- What obstacles appear to be in the way of your new wellness goals?
  - What aspects of these obstacles are physical?
  - What aspects of these obstacles are mental/emotional?
    - How do you define "failure" personally?
    - How do you identify it in your experience as a developer?
    - How do you currently address this pain point?

Each of these answers can be a help in making slight improvements on what you regularly experience, or large sweeping and breaking changes. Both are great things, sometimes things are 95% good with only a 5% margin for improvement. If this is the case, awesome! Changing small things to better suit you is great practice for changing the larger things down the line as you see .

## The Overall Functional Effects of Individual Developer Wellness on The Team at Large

The effects of having more developers than not who are invested in their own developer wellness will make the difference between the presence of a virtuous cycle or vicious cycle.

### What Could Happen When You Do NOT Have Developers Invested in Their Own Well-Being

When your dev team is NOT invested in their own well-being, it can quickly become a glaring obstacle to getting work done in a productive and effective way. Doctor appointments, sick days, coming to work sick are all common occurences when a team is not invested in their wellness. A sick person in office, or one who is out sick often, may become more distant to the rest of the team, initially for reasons of contagions.

Eventually chronically sick people may become sequestered from the rest of the team due to having less context while at work due to being out sick often, or possibly having unhygienic practices that others don't want to be around.

Obviously, this can affect the team as a whole in a negative way. There may grow an unspoken understanding amongst co-workers that working together with a certain person is a less-than-desirable situation because of their constant coughing, or chronic crankiness. As a manager or team lead, it is definitely worth putting some time and money into addressing this potential schism amongst your team.

You may decide to incentivize better health practices and attitudes in order to deal most effectively with this issue. A "wellness" stipend may be a good place to start - allow your team to put company resources towards anything that they each deem a worthy resource towards their own wellness. It could be put towards a gym membership or movement-centric class (yoga, zumba, salsa dancing), or books on self-development in the workplace or even books on computer science principles if they feel that increased knowledge will boost their feelings of being more productive at work.

### What Could Happen When You Do Have Developers Invested in Their Own Well-Being

When your dev team is invested in their own well-being, the air becomes lighter at work. There will be less hesitancy in communication between members about the code, about the technical design, about the last few pull requests. It's okay to move code and logic around as a team, and to talk about these changes from a detached, and pragmatic point of view because everyone understands that they are not the code that they write, and that changes made or proposed are not directed at them in negative, or even personal ways.

A team whose members are invested in their own developer well-being is an example where the sum is greater than the parts. Difficulties and other sticky points become less difficult as a cohesive team instead of merely disjointed members. It’s much easier to assume the best in coworkers with regards to communication, even if there are occasional misunderstandings.

These benefits will exist even on a team where _most_ of the developers are fairly well invested in their own well-being. A virtuous cycle may begin to occur where the more well-balanced personalities begin to exert influence of wellness consciousness on others. As things become generally more pleasant and productive, the rising tide of wellness amongst the team members lifts all boats.

**The team functions as a finely tuned, and well-oiled web development machine.**

## Conclusion

It's been said that _if you enjoy your time at work, you live twice as long._

<figure>
  <img src="/assets/blog/2019-05-15-developer-wellness/happy-kid.jpg" style="display: block; max-width: 100%;" alt="Happy kid">
  <figcaption>Photo by SB Vonlanthen</figcaption>
</figure>

If you treat your own well-being as something to grow and maintain, you will enjoy these benefits: your work will be improved, you will like being at work, you will like the people that you spend time with while working. You will also take more personal satisfaction and pleasure from your time and life apart from work, and create more ways to enjoy it with even more gusto.


Developer Wellness


When the term "legacy code" comes up, it's usually said or received with a tinge of disdain. A preliminary Google search for "legacy code memes" brings up hundreds and hundreds of image macros of people tearing their hair out, looking frazzled, or hugely disappointed.

<img src="/assets/blog/2019-04-26-legacy-code/legacy_meme.jpg" alt="Frazzled looking man with disorganized papers captioned 'explaining legacy code to newly hired employees'" style="display: block; max-width: 100%;">

When I started working as a software developer 6 months ago, I had no idea what legacy code was or what working with it entailed.

During my fourth month as a junior developer, I was asked to add a search filter modal to an app built by one of my coworkers two or three years ago. It seemed easy enough; I'd spent the majority of the last four months working on an incredibly complex app for another client involving our standard stack: [TypeScript](https://www.typescriptlang.org/)/[React](https://reactjs.org/)/[Redux](https://redux.js.org/)/[Redux-Saga](https://redux-saga.js.org/). I had already solved many unique problems and felt confident in my coding ability enough to make a simple modal to pass query parameters to the backend.

As you may have guessed, it wasn't nearly that simple. But why?

## What legacy code is and why it can be challenging to deal with

Legacy code is code inherited from another developer or team which uses older technologies that are no longer supported or have been superceded by a newer version. Many programmers say that "code becomes legacy code as soon as it's written". The functional difference between "regular" code and legacy code could simply be that it has different conventions compared to what you're used to working with.

In my case, the app I was assigned to utilized [Flow](https://flow.org/) rather than TypeScript, and it wasn't as strongly typed as I was accustomed to. This made it a bit harder for me to understand the structure of the data that was being fetched from the backend. No types meant that I was running into TypeErrors on runtime much more frequently, which can be difficult to debug when you're writing a large feature. On top of this, the app used a much older version of React which needed to be reconciled with a compatible version of the component library I wanted to use to build the modal.

Before I get into the nitty-gritty of how to handle legacy code with a sense of poise and rationality, I want to add a disclaimer that legacy code isn't all bad and working on a legacy project doesn't have to be terrible. On the contrary, working on legacy code taught me to be flexible, patient, and above all else, the experience allowed me the chance to solve problems with a new perspective in a novel context.

In fact, it made me a better developer than I was before I started working through the aforementioned codebase, and hopefully your legacy project can teach you something too.

## How to deal with with legacy code on a technical level

<img src="/assets/blog/2019-04-26-legacy-code/old_tools.jpg" alt="Sextnt and leatherbound book on a natural wood bench." style="display: block; max-width: 100%;">
Photo by Jeff Sheldon on Unsplash

### Read documentation and code comments when possible

In a perfect world, every codebase has a robust README that contains concise explanations of how the project works, code comments that explain the exact logic of the original author, and the whole application makes perfect sense. However, this is rarely the case. Many READMEs don't get updated as projects develop, people forget to write comments, assume that their logic is obvious to a new developer, or they simply run out of time to take care of those things.

### Look at the codebase as a whole

If you're lost and don't know where to start, ask yourself these questions:

- What is the app’s purpose?
- How does data flow through the app?
- How does your feature fit into the app?

When you can get a sense of the big picture, it's easier to figure out how best to tackle the problem. Maybe you need to create a new file and create a new component. Maybe you need to write a utility function and test it. Whatever the case may be, understanding the broader context of your problem is a good first step to creating a solution.

### Test the app manually and with unit tests whenever possible

Breaking an app temporarily while adding a new feature is an inevitability, no matter what level of developer you are. This is normal and expected, especially if you're new to the job, working in a legacy codebase with an unfamiliar stack, or some combination of the two.

The best way to prevent these breakages from becoming long term problems is to test your app thoroughly with both unit tests and manual tests. Having these tests in place and knowing exactly what kind of coverage you get out of them will save you and future developers a lot of time. In addition, rigorous tests make the app more scalable and also give you a litte dopamine rush every time your tests run clean.

For unit testing, you can use test frameworks like [Jest](https://jestjs.io/) or [Jasmine](https://jasmine.github.io/).

For manual tests, you'll want to develop a test matrix and make sure the document is accessible to future developers. For the matrix, you'll want to define a set of actions, the expected behavior, the actual behavior when you test it, and any other details that are important, like so:
<img src="/assets/blog/2019-04-26-legacy-code/matrix.png" alt="Spreadsheet for behavior driven development" style="display: block; max-width: 100%;">

I'll be covering how to implement both types of testing efficiently into your workflow in a future blog post.

### Ask for help

Assuming your project was written by a current or former employee at your workplace, someone else probably knows what's going on in the app, or at least knows enough to get you unstuck. Learning to swallow your pride and ask someone else is a an uncomfortable step for some, but a necessary one for growing as a developer, and maybe your coworker can teach you a few new tricks.

A good way to make efficient use of your time (and theirs) is to formulate informed questions. Try going back to looking at the codebase as a whole and figure out the gaps in your understanding. Not only will it help them to get a better sense of what your problem is, but it shows that you took the initiative of trying to solve the problem on your own first.

### Know when to cut your losses

If you’re spending too much time trying to get your foot in the door and haven't made any serious stride towards implementing the feature after trying the steps above, it might be worth refactoring the code around your feature. Don't give up too easily, but also keep in mind what your deadlines are and what your project manager expects from you.

That said, there are drawbacks to going about it that way:

- Rewriting code can introduce bugs, though this can be somewhat circumvented with good unit testing.
- Rewriting code can remove hidden functionality, though this can also be circumvented with good unit tests.
- If you're pressed for time, writing code outside of your feature in addition to your feature might actually be more time-consuming than just building around it.

All in all, use your best judgement. There are pros and cons for either choice, and it's all dependent on your individual circumstances and project budget.

## How to deal with legacy code on a psychological level

<img src="/assets/blog/2019-04-26-legacy-code/meditation.jpg" alt="A man sitting on a dock in a serene mountain lake" style="display: block; max-width: 100%;">
Photo by Simon Migaj on Unsplash

Now that we've covered the technical aspects of dealing with legacy code, let's talk about how to deal with it using our soft skills. After all, developers are people, not just coding robots, and dealing with challenging problems on projects that require creativity and authorship can be emotionally taxing, not only for you, but for your coworkers as well.

### Be humble and kind

This is something that I will sheepishly admit I need to practice more. When I was first assigned the filter modal project, I was fairly vocal about how janky and unappealing the code was to deal with **while the original author of the code was sitting 15 feet away from me.** I intended my comments to be a joke, but in hindsight I recognize that I was being arrogant and hurtful, and that I should have been more empathetic.

There are a lot of factors that can lead to legacy code looking "off" which you should take into account before you start to criticize the author or assume the worst about them (This is loosely tied to the [fundamental attribution error!](https://en.wikipedia.org/wiki/Fundamental_attribution_error)).

#### **The original author may have had their reasons for writing code the way that they did.**

Time constraints and technology constraints can cause a person to write code that works but doesn't necessarily have the best convention. If you picture yourself in a situation with not enough time, outdated tools, and a todo list a mile long, you probably wouldn't write the best code either!

#### **Conventions change.**

In older Olio Apps projects, the convention for code is using single quotes to declare strings, and two spaces was equal to one tab. We had multiple small React components nested inside of a single file. In our current convention, we use double quotes and four spaces, and each React component, no matter how small, lives in its own `.tsx` file in the `component` directory. And in several years, I'm sure that will change too.

#### **All code eventually becomes legacy**

This ties back into the previous point: your code will eventually be legacy. As you move up the ladder of seniority, new developers will be hired on and will have to maintain your old code. You might write clean, flawless, DRY code, but once conventions change or trends change, those new developers might view your code the same way you view the legacy code of others.

### Take pride in the small successes

It’s not easy to work outside of your habitual conventions; there's a reason for the huge trove of memes and jokes about dealing with legacy code. If you've ever learned a language outside of your native tongue, you know how it feels to forget a word or term in your second language, but remember it in your native language and not be able to translate across the gap. The same goes for changing between modern and legacy conventions. Sometimes it just takes a minute to regain your bearings.

In being able to successfully navigate legacy code, you're showing your ability to be adaptable, which is an important skill that benefits you at your current job and all of your future jobs, whether those jobs are in the technology field or not. Legacy code is the perfect playground to practice this skill.

## In conclusion:

### Use this time to bolster your own code writing

Now that you've had the experience of working in a legacy codebase, you should come away from it with a better sense of what you like and don't like in terms of tools and conventions. These are things you can carry on with into future projects, and make you better at reviewing the code of others, offering constructive criticism, and giving mentorship.

### Develop apps for the user **and** the future developer

Whether you've had the experience of great documentation and code comments or no documentation or code comments, you can see how both documentation and comments are powerful tools to help future developers navigate the project. You share a common goal of wanting a smooth, functional, and DRY app; maintaining the documentation and leaving behind informative code comments is a good way of bridging that gap.

### Remember that your code will be legacy someday too

I've mentioned this a few times already, but it's important to reiterate that your code will be legacy too, no matter how DRY and pristine your code and logic are.

The most important takeaway is to be flexible, humble, and that you can definitely learn new tricks from old code.


Legacies Never Die: How to Handle Legacy Code


_Author's note: Inspired by my own recent experience of handling a lot of "newness" all at once, I started writing this blog. While writing it, I realized I was really just writing about my own philosophies on being a developer in general, because so much of what we do involves constant exposure to new ideas and tools. No matter where you are in your career, I hope there's something here to inspire you to learn, grow, and participate in supportive developer communities._

<img src="/assets/blog/2019-04-22-gracefully-handling-newness/new.png"  alt="scrabble pieces" width="100%">

As a software engineer, I find my self torn between two seemingly opposite goals: becoming a master of the skills that I already have and also constantly trying to learn new things. And I'm definitely not alone.

There is some comfort (and a lot of satisfaction) in mastering a subject and having the confidence to tackle any task within your wheelhouse. But equally as satisfying (in different ways) is trading in your "master hat" for your "I'm completely new at this hat", soaking in novel information, and learning a new skill from the ground up. Deep diving into something new, though rewarding and sometimes necessary, can be very challenging.

Sharing a personal example: I had become very comfortable in my web development stack: React/Redux/TypeScript. At the beginning of the year, I became the primary developer on a greenfield project with all new-to-me technology: speech-to-text APIs, Unity, Magic Leap. This was a very exciting opportunity for me, but it also came with it's fair share of challenges.

Along the way, I obviously learned a lot about developing in Unity, programming C#, and working with cutting-edge hardware (Magic Leap One). But I also learned some valuable lessons about how to handle that level of novelty. Here are some tips for handling these challenges gracefully.

## Mindset

A huge part of tackling any challenge is mindset. Some people are naturally drawn to trying new things, while other's prefer to stick to their comfort zones. But things are always changing in software, and learning to love newness and being able to roll with changes will serve you well as a programmer. Here are a couple of things I found helpful to keep in mind while cutting my teeth on several technologies all at once.

<img src="/assets/blog/2019-04-22-gracefully-handling-newness/positive.jpg"  alt="be positive" width="100%">

### Be grateful for this opportunity

Even if trying something new doesn't immediately excite you in and of itself, there are a number of ways it will pay off. Appreciate the opportunity to learn something new, grow your skills, and become an more versatile team member. Think of these challenges as an investment in yourself and your resume.

### A change in pace can be good

While entering new territory, your pace may slow dramatically from your normal work flow. Working in Unity/C# for the first time, it was taking me days to create features that would have taken me hours in TypeScript. Which honestly sucks, but there's lemonade to be made from those lemons.

It was very humbling, which I think is an important part of the personal and professional growth cycle. It helps you remember your roots (we all started from somewhere), and make you more empathetic to new developers. A slower pace can also create more room for reflection and break-taking, which are healthy.

### Perseverance

Giving up is easy. Remember why you wanted to learn this technology and what value learning it can offer. Always reach out for help when you hit a roadblock. Most major technologies have channels for communication, Stack Overflow, or you can use this opportunity to go to a meetup and network with people who can help support you as you learn something new.

## Creating a Solid Foundation

When getting started with something new, try to gain a solid foundation before advancing. This may go without saying, but sometimes our developer prowess can make us forget that. When working in my Unity/Magic Leap/Speech API project, I was tempted to learn all these technologies at once while starting to build the app. In fact, that's how I originally started. However, I quickly realized that was not going to be a suitable way to learn or build the app. I was trying to start at level 5, but I hadn't completed level 1 yet.

Make sure to take the time to practice before jumping into a major project. Once you've completed a couple tutorials, start by integrating the technology into a practice project. The classic example, of course, being a todo list app. If the thought of making another todo list app makes your heart hurt, there are plenty of other options.

If you have a personal project, try adding a new feature or refactor what you have using new technology. Even if this spike never gets merged to production, this helps you keep your personal project alive, gives you extra incentive to keep adding features and helps you practice new things all at once. If you don't have a personal project going, what an excellent time to start one!

Remember: The real value in refactoring existing logic or making another todo list app is that you don't have to worry about doing any logic design (because it's already done), you just get to jump in to applying the new tech.

Depending on the technology or your general experience, getting in the practice could take a few hours, days, or weeks. So it's important to be efficient with your time. Creating a practice plan with time boxed benchmarks can be helpful.

For example (totally hypothetical): I am going to spend 5 hours creating a Unity todo list app with state management. Once I have an understanding of Unity, I'm going to spend 6 hours retrofitting my Unity todo list app to run on the Magic Leap. By the end of the week, I'll add a speech recognition API to the app for adding new items. Things may end up taking more or less time than you expect, but it's good to have a plan.

## Engaging the Community

Some of us prefer to take the lone wolf approach on our learning journeys. But participating in developer communities, especially early on, can really payoff. Many new technologies, the ones with a lot of buzz that you're eager to learn, are surrounded by active communities on forums like Stack Overflow, Slack, GitHub, and even local meetups.
<img src="/assets/blog/2019-04-22-gracefully-handling-newness/engaged.png"  alt="be engaged" width="100%">

### Learning

These online or in-person communities are great resources for receiving help. Working alone, you might find yourself blocked by a problem for days, unable to make meaningful progress. Chances are, you're not the first person to experience this pitfall and a fellow coder could help illuminate the path forward.

### Social Support

Next, not knowing something or stepping into unknown territory can feel very isolating. Meeting others in similar positions can help ease the emotional burden of the learning experience. With community support, learning can be fun, especially when you have someone (and somewhere) to share your wins.

### Honing your Craft

Engaging with a community is also a great way to expose yourself to different styles of coding. You will get a glimpse into other people's projects, what technology they're using, and how their using it. You'll have an opportunity to interrogate other people's code and also pick up tips and tricks to add to your own coding style.

### Giving Back

During this process, take the opportunity to give back to the community. You can do this in a lot of different ways: Write a blog post about your experiences, share your code, answer questions, request new features, point out areas for improvement in documentation. You could even PR into an open source library once you've honed your skills.

## Recognize Patterns & Find what is Familiar

Good patterns tend to repeat themselves in software. Even if you find yourself in what feels like completely unfamiliar territory, most of the skills you’ve used to develop apps in one language, framework, or discipline will still be applicable. For example, if you’re taking the leap from frontend state management to database management on the backend (or vice versa) you’ll notice the event driven architecture of both hum to the same tune.

By recognizing these similarities, you'll be able to learn faster. Try to implement code in a way that feels familiar. If the way you normally write code is clean, efficient, well-documented, and structured appropriately you’ll be able to find your groove in no time. (And if you don't, what a great time to start!)

Identifying these patterns may also help you gain a more solid understanding of your already familiar tools. For example, after using it for years, I found that there was a lot to my current development stack that I took for granted. While implementing state management from scratch in my Unity project, I gained a new appreciation for the mechanisms underpinning the unidirectional data flow in Redux and the value of having a single source of truth.

## Reflection & Sharing

During your learning journey, take time to reflect and share your experiences. I recommend keeping a daily developer journal of your highs, lows, pitfalls, and “ah-ha” moments. This way you will have a record to look back on when you want see how you have progressed over time, want to gather material to share with others, or when you need inspiration. You have a number of tools to choose from to help get this job done: [jrnl](http://jrnl.sh/), [notion](https://www.notion.so/), good old notebook, just to name a few.

If you’re working as part of a team, candid daily reflection in scrum standup is a great way to share your learning experiences. Just like engaging an online technology-focused community, this can help you get through blockers, inspire others on their own learning journeys, and maybe create a supportive micro community inside your workplace.

Reflecting and sharing may seem tedious, especially on top of the stress from learning a new subject, but I think the benefits make it worth while. First, sharing what you've learned, where you got stuck, and how you got un-stuck could help other developers who are new to this topic. Second, reflecting on your experiences and teaching others will help reinforce what you've learned. Third, sharing along the way, especially with coworkers and friends, keeps you accountable and can help you persevere through rough patches.

## Conclusion

There are always going to be opportunities to learn and grow in the field of software development, and I hope you take as many as you can. As you learn new things, you are improving your creative thinking skills and creating muscle memory in your brain for handling "newness". The more skills you have learned, the faster you will be able to pick up new ones. Having the right mindset, creating a solid foundation, engaging communities, recognizing familiar patterns, and reflecting on your experiences will help you tackle these challenges with ease.


Gracefully Handling Newness: Tips for Software Developers 


Another quarter, another chance for the staff at Olio Apps to try their hand at hacking together a project over an 8 hour work day in a friendly competition. If you haven't seen our first attempt at a Hackathon, check out our previous blog post on it [here](https://www.olioapps.com/blog/hackathon/). We enjoyed the experience so much, we decided to make it a quarterly tradition as a way to bond, break out of our normal developer mindset, and come up with new ideas or learn new tools.

## Shoutbase

For this Hackathon, we wanted to focus on improving one of our current products [Shoutbase](https://www.shoutbase.com), a tool for tracking time spent on projects or tasks, either as an individual or as a team with fast setup and customizable project tags.

<img src="/assets/blog/2019-04-01-second-hackathon/shoutbase.png" style="display: block; max-width: 100%;" alt="Screenshot of of Shoutbase dashboard">

We broke up into pair teams, and came up with fairly diverse ideas, transforming the capabilities of this app in three distinct ways.

### Cory & Jason

Cory and Jason decided to take on integrating [GraphQL](https://graphql.org/) as a way of improving Shoutbase's developer-side experience. After spending time in this codebase, they were inspired to use GraphQL to make it more scalable and easy to reason about. At the end of the day, they migrated enough client side and server side code to power an admin dashboard. They learned that the predictability of GraphQL makes it easy to test queries in the GraphQL playground without needing the client and also that sticking to easy to implement features makes code migration much easier.

<img src="/assets/blog/2019-04-01-second-hackathon/graphql.png" style="display: block; max-width: 100%;" alt="Screenshot of of GraphQL Playground using one of our queries">

### Stormi & Ami

The idea of keeping a "Developer Journal" has been a prevalent theme not only in the office, but in the developer zeitgeist as a whole, which is a large part of the reason Stormi and I chose to tackle adding the journaling capabilities to Shoutbase. We wanted the app to be more of an all-in-one tool for not only tracking time, but tracking how things went, personal "wins", and how the user felt about the task. We created a new tab for journal entries, which were posted in a format as normal time entries with field for adding a sentiment and text formatting markdown. The idea was that being able to track and visualize mood or sentiment over time in tandem with project tasks would allow the user to communicate during one-on-ones with a project manager to assist with goal-setting and enhance professional growth.

<img src="/assets/blog/2019-04-01-second-hackathon/shoutbase_journal.png" alt="Screenshot of Shoutbase entry with markdown formatting and a scatterplot" style="display: block; max-width: 100%;">

### Jon & Frank

Jon and Frank decided to go a more experimental route and began to toy around with [WebAssembly](https://webassembly.org/) as a tool to reduce load times with smaller file transfer, and faster performance of CPU-intensive computations. In Shoutbase's case, a team admin, who can see all of the time entries for their team members, would be able to see massive amounts of bucketed time entry data potentially ["up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps."](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/)

## Judging

Judging for this Hackathon was done by Jesse Hallett, friend, former colleague, and [contributor](https://www.olioapps.com/blog/automatic-code-formatting/) [to](https://www.olioapps.com/blog/checking-types-real-world-typescript/) [our](https://www.olioapps.com/blog/the-lost-art-of-the-makefile/) [blog](https://www.olioapps.com/blog/type-driven-development-with-typescript/). The projects were judged based on their concept, utility and implementation. In the end, Stormi and I were awarded extra vacation days (and I go undefeated in Hackathon wins 😁).

## Takeaways

This Hackathon was a lot of fun and it was awesome to try our hand at hacking on the same base product with totally different results. One thing we learned about participating in an event like this (and in general, really) is to be sure to _scope your project appropriately for the amount of time you have_. Another thing we learned through this process is the importance of being able to present and explain code that doesn't necessarily tie into the user interface.

All in all, it was a great experience. We discussed future formats and themes for the next Hackathon and the one I'm looking forward to is splitting the office into two teams led by our bosses Scott and Aron in a larger swarm format, and we're still working out a partnership with a local non-profit to hack a project together for them, so stay tuned.


Quarterly Hackathon 2: Harder, Better, Faster, Stronger


When you have a new idea for an app, you want to get feedback from users as quickly as possible to see if the idea has legs, and start refining it. The best feedback comes once people try it.

So, our primary goal is to make it possible to get real user feedback from people using the app as soon as possible.

In this post, we'll begin creating an app and make it possible to share it with others within 5 minutes so they can give you feedback as you build it.

Secondary goals

- Native App - not a responsive web app running in the browser, a fully native app
- Skip the app stores - getting an app approved in the app stores is an involved, time-consuming process.

Given these goals, one of the best sets of tools available today is React Native and Expo.

[React](https://reactjs.org/) is a declarative, efficient, and flexible JavaScript library for building user interfaces.

[React Native](https://facebook.github.io/react-native/) is a framework for building native iOS and Android apps using React.

[Expo](https://expo.io/) is a tool for creating React Native apps quickly. With Expo, you can start a new app, preview it in the browser, then see it on your own device, and share it with others almost immediately (5 minutes).

## Get a taste with Snack

<img src="/assets/blog/2019-03-18-rapid-prototyping-react-native-expo/rapid-prototyping-react-native-expo-snack-640.gif"  style="margin: auto;display: block;" alt="Snack">

[Snack](https://snack.expo.io/) is a lightweight online IDE for Expo that allows you to run code in the browser in a matter of seconds. It's great for quick experiments and sharing examples.

Go to [snack.expo.io](https://snack.expo.io/). You'll see some code, and an image of an iPhone, with a large "Tap to play" button. Tap it, and the app will boot in a device simulator.

Change the text in the code and it will update.

## Install the Expo toolchain

First, install [Node.js](https://nodejs.org/). The latest version is recommended.

Second, install the Expo package for Node.

```shell
npm install expo-cli --global
```

Third, install the expo mobile app on your device. Either [iOS](https://itunes.apple.com/us/app/expo-client/id982107779?mt=8) or [Android](https://play.google.com/store/apps/details?id=host.exp.exponent&hl=en_US).

## Create a new app

Once everything is installed, you can run the following commands from your terminal to get a new app running in development.

```shell
expo init my-new-project
cd my-new-project
expo start
```

## Scan app QR code to run it on device

You will see a QR code in terminal and Dev Tools. To open your project on your device, simply scan the QR code with the Expo Client app on Android or using the built-in QR code scanner of the Camera app on iOS.

## See your changes immediately

- Edit the home screen `screens/HomeScreen.js`
- Watch your device refresh

## Notice what we did not do

- No Apple developer program registration ($99 + days)
- No creating code signing certificates
- No cable from the computer to the device
- No compiling in Xcode
- No uploading to TestFlight
- No inviting users to TestFlight
- No app store review process

Of course, we will want to do these things too, but only when we are ready to launch. By that time, we will have validated and improved our idea with real user feedback so it can be truly great.

And we won't have to start over with a different platform or framework to get there. React Native and Expo supports the full life cycle from development to app store deployment.

Do you need an app prototyped or built fast? Olio Apps can help. We have built and shipped multiple iOS and Android apps to the app store. [Tell us about your project!](mailto:sayhi@olioapps.com)


Rapid Prototyping Native Mobile iOS and Android Apps in 5 minutes with React Native and Expo


[Sitka][sitka] is a small but powerful framework for state management. It organizes your application into modules, each managing a logical area of state. It builds on top of Redux and Redux Saga, giving you all the benefits of those tools without the boilerplate.

Lets examine a simple counter application, contrasting the differences between a traditional [Redux][redux] / [Redux Saga][redux-saga] implementation and a Sitka implementation.

## A simple counter application

For the purposes of illustration, we'll work with a simple counter app built using [TypeScript][typescript], whose state exists in a Redux store, and uses Redux Saga to coordinate its logic.

In simple applications, it may be enough to change state by calling an action directly consumed by a Redux reducer. However, in larger apps, Sagas offer a useful mechanism for triggering compound operations around a single logical action such as "increment counter". For example, the increment action might require permissions checks, logging, and even asynchronous access to a secondary data store before finally calling a reducer to change state.

The counter app discussed here is a simplified model of a much larger application, similar to others we’ve created at Olio Apps.

## The traditional way

Building the counter app using TypeScript, Redux, and Redux Saga will require:

0. the counter state in Redux
1. an interface for the increment action creator
2. an action creator that uses the interface
3. a listener for this action in the Sagas index, routing to a Saga
4. a selector to get the current counter state from Redux
5. a Saga, which handles the action's payload as well as any other application side-effects, and setting a new value in Redux state via reducer, using a second Redux action creator
6. an interface for this reducer-facing action creator
7. an action for the reducer-facing action creator
8. a reducer listening for the value-setting action creator
9. registration of the reducer with the root reducer

Below we have a fully realized implementation of these components:

```typescript
// 0. create the shape of the managed part of state
interface Counter {
    value: number
}

const defaultCounterState: Counter = { value: 0 }

interface AppState {
    counter: Counter
}

const defaultAppState: AppState = {
    counter: defaultCounterState,
}

// 1. interface for action creator to handle increment
interface HandleIncrementAction {
    type: "HANDLE_INCREMENT",
}

// 2. action creator to handle increment
const handleIncrement = (): HandleIncrementAction => ({
    type: "HANDLE_INCREMENT"
})

// 3. a listener in the root saga
default function* root(): {} {
    yield [
        takeEvery("HANDLE_INCREMENT", handleIncrement)
    ]
}

// 4. a selector function to get a specific part of Redux state
function selectCounter(state: AppState): Counter {
    return state.counter
}

// 5. a saga function to handle side effects and/or payload
function* handleIncrement(action: HandleIncrementAction): {} {
    // uses the selector defined in step 4
    const counter = yield select(selectCounter)

    const newValue = counter.value + 1

    // uses the action/interface defined in steps 6 and 7
    yield put(actions.setCounter(newCounter))
}

// 6. interface for action creator to set new value in state
interface SetCounter {
    type: "SET_COUNTER"
    value: number
}

// 7. action creator to set new value in state
const setCounter = (value: number) => ({
    type: "SET_COUNTER",
    value,
})

// 8. a reducer listening for the action called in step 5
function counter(
    state: Counter = defaultCounterState,
    action: SetCounterAction,
): number {
    switch (action.type) {
        case "SET_COUNTER":
            return { ...state, value: action.value }
        default:
            return state
    }
}

// 9. reducer is registered with the root reducer, and a store is created from it
const rootReducer = redux.combineReducers({
    counter,
})
const store = createStoreWithMiddleware(rootReducer)
sagaMiddleware.run(root())
```

TypeScript, Redux and Redux-Saga are great to use together. You gain all the advantages of a strongly-typed codebase, Redux state management, and straightforward control flow of both synchronous and asynchronous operations.

But as you can see from above, an obvious downside of this stack is that typical usage requires a lot of boilerplate! That is where Sitka comes in handy.

## Implementing the app using Sitka

Sitka dramatically cuts down the amount of boilerplate. All the code that is needed to accomplish the same counter application above can be written using Sitka like this:

```typescript
// define the piece of state managed by your module
interface CounterState {
  readonly value: number
}

// define the modules under control by Sitka, which includes the module below
interface AppModules {
  counter: CounterModule
}

class CounterModule extends SitkaModule<CounterState, AppModules> {
  // corresponds to the key in Redux that contains the state managed by this module
  public moduleName: string = "counter"

  public defaultState: CounterState = {
    value: 0,
  }

  // because this method is public and prefaced by 'handle', it will be wrapped in an action and
  // available to client code such as React components
  public *handleIncrement(): {} {
    const counter: CounterState = yield select(this.getCounter)
    const newValue = counter.value + 1
    yield put(this.setState({ value: newValue }))
  }

  private getCounter(state: AppState): CounterState {
    return state.counter
  }
}

// instantiate an instance of Sitka, and give it the modules
const sitka = new Sitka<AppModules>()
sitka.register([new CounterModule()])
```

A full counter application can be found [here on Github][counter-app].

A `moduleName` and `defaultState` are set within the class, and a single generator function `*handleCounter` is defined, which simply increments the counter by 1.

The `public` and `private` keywords are used to show which class methods are callable from outside of the class itself. For more about this feature of TypeScript, see their handbook about [classes][typescript-classes]. In this case, `getCounter` is marked `private` so that only `CounterModule` has access to its own state.

This is much less code than the first example. This makes it more maintainable and easier to reason about. Overall, this leaves you with a cleaner codebase.

In your presentational component, this is how you might call `*handleIncrement`:

```typescript
const { counter } = sitka.getModules()

// this fires a Redux action that
// Sitka uses to increment counter
<button onClick={counter.handleIncrement}>INCREMENT</button>
```

The `handleIncrement` generator defined in your module is wrapped in an Action that is created under the hood, because its name starts with `handle`.

## What’s happening under the hood

Sitka spares you from writing boilerplate by autogenerating code. It generates:

- An action wrapping each generator function
- A reducer backing the setState method
- A section of the redux state tree, defined by the sitka class attribute `moduleName` - in this case `counter`.

## When should you use Sitka

We recommend using Sitka if you intend to build a larger application using typescript and redux. Sitka keeps your code strongly typed and organized, while reducing the boilerplate burden of that redux and typescript can add out of the box. Less typing = faster development time.

## Upgrading existing applications

Though you can build your application from the ground up using Sitka, it's also designed to be incrementally added to an existing Redux application. See an [example of adding Sitka into a project][add-sitka], and an [example of usage][react-redux-connect] using React-Redux's `connect` function to connect your component to a Sitka-powered Redux `store`.

## Olio Apps is using Sitka

We are using Sitka in live projects, and it's delightful to work with. We get to take advantage of all the benefits of a strongly-typed codebase, while also enjoying writing a small fraction of the code we needed before using Sitka. We at Olio Apps hope you try out Sitka to manage state in your next project, or even to implement a new feature in your existing project.

[sitka]: https://github.com/olioapps/sitka
[typescript]: https://www.typescriptlang.org
[redux]: https://redux.js.org/
[redux-saga]: https://redux-saga.js.org/
[counter-app]: https://github.com/frankmeza/sitka-counter-ts
[add-sitka]: https://github.com/olioapps/sitka/wiki/Adding-Sitka-to-a-Redux-store
[react-redux-connect]: https://github.com/olioapps/sitka/wiki/React-web-usage
[typescript-classes]: https://www.typescriptlang.org/docs/handbook/classes.html


reduce boilerplate and manage redux state using sitka modules

Reduce Redux Boilerplate with Sitka

Recently, Olio Apps took a little break from our regularly scheduled programming (😜) to do some hacking. We broke off into teams two, designed and built projects over the course of a pizza-fueled "work" day.



## Projects

The Hackathon had an open ended set of themes including: Continuous Improvement, Emerging Languages and Frameworks, Virtual Reality, and Technology for the Greater Good. The primary goals of the Hackathon were to encourage teamwork, practice new technologies that we're excited about, and have fun. With our eyes on the prize (extra vacation days to the winning team), we got to hacking. This was the result:

### Cory & Frank

Cory and Frank were the _Slackers_. Their project was to create a prototype for a Slackbot Developer Journal to prompt you throughout the day and ask you questions about your development process. The purpose is to collect data about your daily experience as a developer and to help you track your continuous improvement in an informal way. Example prompts include: How is your coding going? Are you able to stay focused? Are you having a stellar day?

<img src="/assets/blog/2018-12-21-hackathon/notification.png" style="display: block; height:120px; margin:auto"  alt="slack notification">

The Slackbot asks these questions in a private channel and the responses are recorded in a developer journal. The user can look back on their reflections, improvements, and little tips that might have been otherwise forgotten. Developer journaling is an excellent tool for keeping track of your progress (especially when it comes time for your annual review). However, it can seem tedious to break from your work cycle and carve out time for journaling. The Developer Journal Slackbot solves this problem by offering quick, voluntary prompts that allow you to reflect on your current work rather than distracting you.

### Scott & Ami

<img src="/assets/blog/2018-12-21-hackathon/weekly.png"  style="margin-right:20px; width: 50%; min-width: 300px; display:inline;" align="right" alt="Weekly Planning App">

Scott and Ami decided to use the Hackathon as an opportunity to give back to the team by creating something we could all use. Every Monday our team gets together for a "Weekly Review" meeting where we set weekly goals for each of our projects and review the goals from the previous week. Currently, this is done by editing a raw text file and committing the changes to a git repository. It results in a nice running text-based log of what the company was doing each week. However, the process involves a lot of copy-pasting and can be a bit tedious for the note taker.

So, Scott and Ami used Sketch to mockup a nice design and then got to work creating an app using Electron and React that could parse the text document into editable projects and tasks. By the end of the day, they had a slick looking user interface complete with keyboard shortcuts for easy editing. With just a little more polishing (including automating git operations) we'll be able to work this application into our weekly routine. Their tips creating a successful hackathon project include keeping your scope small and to think about the design up front.

### Stormi & Aron

<img src="/assets/blog/2018-12-21-hackathon/hack1.jpg" style="margin-right:20px; width: 50%; min-width: 300px; display:inline;" align="left" alt="Presenting WebVR project">

Over the past few months, Aron and I (Stormi) have been working on a side project, the [A-Frame Typescript Toolkit](https://github.com/olioapps/aframe-typescript-toolkit), which is a library for writing WebVR experiences using Typescript. We took the Hackathon as an opportunity to test the toolkit and use it to create custom A-Frame components for making graphs in VR space. Ultimately, we were able to create two different kinds of data-responsive graphs, 3D bar charts and scatter plots, and build a VR data visualization experience that allowed you to walk around a "forest" and discover charts hidden among the trees. The Hackathon helped illuminate some strengths as well as areas of improvement for the toolkit, and were thankful for the opportunity to hack with it over the course of a day.

### Jon & Jason

<img src="/assets/blog/2018-12-21-hackathon/music.png" style="margin-right:20px; width: 50%; min-width: 300px; display:inline;" align="right" alt="Music App">

Jason and Jon decided to use the hackathon as an opportunity to learn more about a couple different technologies. After attending a GraphQL workshop earlier this year, they were inspired to dive deeper into [Apollo](https://apollographql.com) and [Prisma](https://www.prisma.io/). Using GraphQL on the backend and Electron on the frontend, the team created a fresh user interface for finding new music from your favorite artists using the Mixcloud API. By the end of the day, they had a fully functional desktop music app, and they learned more about how Apollo manages client side state with its cache API and how easily it produces optimistic UI by providing a loading component when fetching data.

## Judging

Judging for the Hackathon was done by the esteemed Buck and Rob, designers (and friends!) from a neighboring office. The projects were judged on criteria including completeness, utility, design, and presentation. After much deliberation, Scott & Ami were our worthy winners, creating an application that we'll be able to add to our weekly planning routine.

## Takeaways

We had fun and learned a lot from our first Hackathon experience as a team. One major reminder that came out of the Hackathon is that there is a big difference between "hacking" and "software engineering." When hacking, you focus more on rapid iteration and less on stability and get to exercise a different part of your brain. We try to avoid "hacking" in our day-to-day work, but it can be a great way to try out new technologies and practice different types of problem solving. We'll definitely be scheduling more internal Hackathons in the future. We're excited to try out different formats, including multi-days, diverse judging panels, and more focused themes. Next time, we'd like to partner with a local non-profit and create some tech for good.

The Olio Apps Inaugural Hackathon


We love TypeScript. I’ll get into the reasons why later. And we love virtual reality. Being able to create [WebVR](https://webvr.info/) experiences has been a focus at Olio Apps this year. This lead us to create a set of tools to help developers to make [A-Frame](https://aframe.io/) experiences using TypeScript. [`A-Frame TypeScript Toolkit`](https://github.com/olioapps/aframe-typescript-toolkit) makes it easy to build standalone components and systems that can be used in other A-Frame projects.

## Why TypeScript?

[TypeScript](https://www.typescriptlang.org/) is a typed superset of JavaScript that compiles into plain JavaScript and it is our frontend language of choice. For the reasons below, we created a set of tools that would bridge WebVR development and TypeScript.

### Development Velocity

First, we’ve found that strict typing help us read and write code faster. The code is self-documenting, indicating what model is expected at every step. This information makes the code more readable and helps the developer understand what each piece of code is doing faster.

### Better Code

In addition to writing code faster, TypeScript also helps us write better code. In one way, it forces the developer to consider the structure of data more carefully. The code is more thoughtfully written with deep understanding of data structures and how models are related. Beyond that, TypeScript also finds more errors at compile-time rather than run-time so less problematic code gets pushed to production.

### Features and Tooling

Finally, the tooling and features available for TypeScript make the language a valued member of our development stack. A major benefit is that it comes with full ECMAScript 6 feature support. Because the TypeScript we write is compiled to JavaScript readable by our target browser, we are able to take advantage of the newest JavaScript language features.

Additionally, a great tool that TypeScript affords is [Visual Studio Code TypeScript Intellisense](https://code.visualstudio.com/docs/editor/intellisense) which offers code completion, hinting, and type definitions that significantly improve the development process.

## Why A-Frame?

A-Frame is a web virtual reality framework. We chose A-Frame because it is a powerful open-source framework with great documentation, a supportive community, and excellent learning material. A-Frame is good for beginners to VR development but can also be scaled to make larger VR (and MR) applications. If you are new to VR development, I highly recommend reviewing the [documentation](https://aframe.io/docs/).

## A-Frame TypeScript Toolkit Overview

The toolkit we have created at Olio Apps combines the power of TypeScript with the accessibility of A-Frame making it easy to develop WebVR.

### Base Classes

At its core, the toolkit provides wrapper classes creatively named `ComponentWrapper` and `SystemWrapper` which allow you to create strictly typed A-Frame components and systems. These base classes contain all the A-Frame lifecycle methods that can be overridden to suit your desired behavior when you extend the class to create your own custom component or system class.

### CLI

The toolkit also contains a CLI which, when globally installed and initiated, makes getting started a breeze. Currently, the CLI supports creating standalone components and systems that can be exported to npm and shared in other A-Frame projects. I’ll discuss more details on using the CLI in the `Quick Start Guide` section.

### Release Support

Equally important to creating VR experiences and Apps is creating assets that can be shared across A-Frame projects. The toolkit contains boilerplate code and instructions to help compile your TypeScript components, systems, and entities into A-Frame code that can be exposed via a CDN and used in A-Frame HTML the traditional way. Because the TypeScript gets compiled into JavaScript, consumers of your TypeScript A-Frame component don't need to use TypeScript in order to use your component.

## Quick Start Guide

The fastest way to get started making custom systems and components using the toolkit is through the CLI. The starter code generated by the CLI not only includes starter code for components or systems (your choice) but also includes build commands and webpack configurations to expedite the development process. Complete the following steps to get started developing WebVR with TypeScript.

### 1. Global Installation

Globally installing the toolkit will allow you to use the CLI to generate a VR project from anywhere on your computer.

`yarn global add aframe-typescript-toolkit` (or npm install -g aframe-typescript-toolkit)

### 2. Initiate Project with CLI

Using the command line, navigate to the directory where you would like to add your new A-Frame TypeScript project.

Run the command to initialize the toolkit: `aframe-typescript-toolkit`

<img src="/assets/blog/2018-12-03-aframe-typescript-toolkit/toolkit.png" style="max-width: 100%;"/>

You will be prompted to select from `Component` or `System`. Choose `Component` for starters.

Enter your project's name (this will be the name of the new directory). Use `new-component` for now.

### 3. Install & Serve

Navigate into your new project directory: `cd new-component`

Install dependencies: `yarn install`

Build the project: `yarn build`

And start the server to see the boilerplate component in action (http://localhost:3000/) : `yarn server `

### 4. Customize

The project generated by the CLI comes with a README that includes tips on customizing the component (or system) and can point you to resources to help the process. While the server is running, changes made to the files in the `/src` directory are served hot to help you test and debug your creation.

Click the video below to see how you can edit the program in Visual Studio Code and watch your changes be dynamically applied in the browser:

[![A-Frame TypeScript Toolkit](https://img.youtube.com/vi/bazU6D-LYDI/0.jpg)](https://www.youtube.com/watch?v=bazU6D-LYDI "A-Frame TypeScript Toolkit")

### 5. Share

Sharing your new custom component is easy. Run `yarn build` to create CDN or npm publishable artifacts in the dist folder.

## A-Frame TypeScript Redux

Another thing we love, beyond TypeScript and WebVR is Redux. Which lead us to use this A-Frame TypeScript Toolkit to create redux-store aware systems and components. This library is called aframe-typescript-redux and it is an excellent example of using the toolkit to create A-Frame artifacts that can be shared. See our previous [post](https://www.olioapps.com/blog/aframe-typescript-redux/) and read the [documentation](https://github.com/olioapps/aframe-typescript-redux) to learn more.

## Conclusion

Creating custom components and systems are a great way to start contributing to the WebVR community. If you are familiar with TypeScript (or eager to learn it) and excited about WebVR development, give the toolkit a try. We would love to hear your feedback and see the projects you create.


Announcing new tools for WebVR using TypeScript

A-Frame TypeScript Toolkit: Creating WebVR with TypeScript


Here at Olio Apps, we have taken the next step into the world of augmented/mixed reality and added a Magic Leap to our catalog. This decision was driven by our interest in the mixed reality space and the possibilities of the domain.

At first, we were surprised by how quickly our unit arrived. We were told it could take up to 90 days but we had it on our faces within a week. The unboxing experience is quite nice and they clearly have taken the time to design an aesthetically pleasing product all around.

<img src="/assets/blog/2018-11-16-magic-leap-first-impressions/ML2.jpg" alt="Unboxing the Magic Leap" style="width:100%">

## The experience

The first hour with the unit was primarily setup. After getting through this step, I installed the fun things! The Create App was the first application I got familiar with. The meshing process is pretty impressive. It does meshing at what I consider an acceptable speed and remembers the rooms you have previously mapped. I did notice that it has a hard time meshing dark objects, such as my black desk chair, but if you get close enough it will eventually recognize it. Once the mapping process is completed, it renders what I would call a projector screen menu. You have to pull the bottom of the menu down to reveal your options. Then, placing items and characters around the room is quite fun.

<img src="/assets/blog/2018-11-16-magic-leap-first-impressions/mesh.jpg" alt="Meshing example" style="width:100%">

One oddly disappointing thing about the mapping process was having to close all the window shades. It had a hard time mapping with sunlight entering the room. It also doesn't tell you why it's struggling to map the room. This is possibly a feature request for their dev team.

The visual experience was unique. Once the device calibrated to my vision the renderings were crisp and stable to my movements. I did notice some slight halo effects after a while but it wasn't intense enough to be distracting. After long periods of time, the weight of the headset actually started to hurt my nose.

## Developing

To start developing, I had to register a [creator account](https://www.magicleap.com/creator). Once you have a creator account, a new menu appears within the Lumin OS settings menu allowing you to access the device from your development computer. There was actually a hiccup with my account and I had to contact support to get the creator menu to appear and unlock the ability to install my own software.

<div style="max-width:50%;">
  <a href="https://www.magicleap.com/creator"><img src="/assets/blog/2018-11-16-magic-leap-first-impressions/registration.png" alt="Creator signup" style="width:50%;"></a>
</div>

Once the creator menu is unlocked, it allows you to enable [mldb (Magic Leap device bridge)](https://creator.magicleap.com/learn/guides/magic-leap-device-bridge-overview). To use mldb, you install the Magic Leap package manager and it handles installing and updating software related to developing for your device. The installation and setup for this was a breeze. I found that the Magic Leap remote application quite easy to set up for simulating a room for development so I wouldn't have to be linked to the device at all times. It was also enlightening to find that I could use mldb through WIFI and know that my development computer wouldn't have to be connected at all times.

The documentation on the [creator site](https://creator.magicleap.com) I found to be very helpful. I could easily locate and implement whatever I was curious about at the moment (such as capturing what the user is seeing in a photo or video).

<img src="/assets/blog/2018-11-16-magic-leap-first-impressions/frank.jpg" alt="Frank wearing the lightgear" style="width:100%">

## Customer Support

While the setup and usage of the Magic Leap was initially good, we did end up having an issue with ours. Mapping the room and navigating with the controller touchpad were all working well, but a few applications rely on the controller being tracked to point and grab things. After about a day of use, the headset was no longer tracking the controller. We tried everything from a factory reset to updating the OS and the controller firmware. I reached out to customer support regarding this and their responses were initially few and far between. On average it took them about two days to respond with very sparse instructions on how to debug. I did most of my debugging research on their forums following those who were experiencing similar issues. After about two weeks someone on their support staff finally offered to exchange the device and we had a new one in our office in only a couple of days.

<img src="/assets/blog/2018-11-16-magic-leap-first-impressions/ml_controller.jpg" alt="Magic Leap controller" style="width:100%">

## Conclusions

Overall, the Magic Leap is pretty amazing. To me, it represents a huge opportunity in areas of education and training and I believe the Magic Leaps size and capability will only improve over time. I am personally learning c++ to get familiar with the [C API](https://creator.magicleap.com/learn/reference/public/v0.11.1/CAPI/index.html). This is really only the beginning.

<img src="/assets/blog/2018-11-16-magic-leap-first-impressions/headset.jpg" alt="Lightwear headset" style="width:100%">


Reinforced Learning