Microsoft – Week 1

I’m tying into my blog to provide weekly updates of my experience here at Microsoft. This post will serve as an introduction to both me and the internship program; some of this may seem a little redundant if you’ve already read my About page.

Hey there! I’m Aidan Brady, and this here is my first blog post as a Microsoft intern. I’ll be working under the “Developer Experiences” (or DX) team which encompasses development partners, education, and platform evangelism in general. I’m writing this post just so soon not because I don’t have anything to do, but rather because so much has already happened and I don’t want to lose track of it all!

A little bit about me: I’m 17 years old, a rising senior in high school, and an almost-11-year resident of Atlanta, GA (where it is currently near 100 degrees, thank goodness I’m here in Redmond). I’ve had an interest in computers for as long as I can remember, and I’ve been doing serious programming for close to seven years now. I’ve dabbled in Python, Swift and C++, but Java is definitely my specialty; alongside my most popular project, Mekanism, I’ve developed countless Java-based applications that I still maintain.

Outside of the tech world, I play piano, tennis (even though I’m one of the worst tennis players I know), love to run with either my music or my friends, and am known to spend quite a few hours at a time watching various shows on Netflix. Speaking of which, if you don’t watch Mad Men, you really should.

I arrived here in Seattle this past Saturday and am staying just across the street from the Microsoft campus at an “Extended Day America,” where I am accompanied by my parents due to what I assume are child labor restrictions. On the start of day one, I still didn’t quite believe I was actually going to be working for Microsoft, and I honestly still don’t. Every employee I talked to was welcoming and more than happy to answer my silly questions (“Where’s the restroom?” “Is the coffee free?” “How exactly do I get out of this building?”) – that includes the college interns who I work alongside in my shared office space. And yes, by the way, the coffee just so happens to be free!

Unlike some internships, there was really no “lazy warm-up period” – right after lunch orientation I was assigned my office and computer and briefed on how my next seven weeks would look. I spent the rest of the day filling up my computer with some shiny new Windows betas, including fancy copies of Visual Studio Enterprise 2015 and Office 2016 which managed to download in minutes thanks to the company network’s gigabit internet. And just like that, I finished my first eight-hour workday at Microsoft. I was in heaven.

Day 2 consisted of me finishing my computer’s setup, grabbing lunch with my intern co-workers, talking with my mentor and attending my first real meeting (woo!). I also found myself already habitually checking Outlook for new emails, and discovered that my calendar was rapidly filling up with company events. As I downed my sixth cup of coffee in my shiny new Microsoft mug, I was feeling like a true employee.

The third day was quite a bit more busy. After doing a bit of work on one of my programming projects in the morning, I took a 30 minute 8:45 shuttle to Redmond Town Center (RTC) where I met with Briana Roberts from the Learning Experiences team, a group within the larger DX organization, that is likely to take a good bit of my time throughout the rest of my internship. After a short meeting, I learned that aside from writing up these blog posts, I’m going to appear in weekly video blogs, work with the Harvard-hosted CS50 event, as well as serve as a judge during for Imagine Cup – and these are just the projects I remember off-hand. I hope I have a chance to work with the Minecraft team, too!

And here I am at the end of my fourth day! I had to get started a bit earlier to be able to hop on a shuttle to the CS50 Bootcamp, but that wasn’t too hard now that I’m getting adjusted to the three-hour time change. I didn’t exactly know my role when I first got there so I got myself some of the free catered breakfast (really good) and took a seat – the actual event started about 20 minutes later. After David Malan, the star of CS50, finished his speech, the attending teachers all filed into another room where tables were set up for different groups – the goal was to come up with a curriculum to teach students the basics of computer programming. Without clear instruction of what I was supposed to do, I decided to just take a seat at one of the tables and help a group with their lesson plan. I realized that I actually could contribute a lot to the conversation, being a student myself! After an insightful discussion on the issues with a typical course-based computer science education, we came up with a plan that involved a more individualized approach to programming, with students following their own projects that interest them and learning various concepts along the way – kind of like the way I learned. Little did I know that the outcome of this planning, however, was to actually teach it – David had a big group of students come into the room, and we all were paired up to have real one-on-one computer science instruction sessions. And that is how, on day four of my Microsoft internship, I became a computer science teacher.

My time here is definitely going to be busy, but it’s by all means going to be fun, and the experiences and connections I will make I’m sure I will take with me far past college. I have a new-found appreciation and respect for Microsoft, too.

Oh!  The Microsoft Learning Experiences is starting a weekly video series of some of us LeX interns, and I happen to be one of them. I’ll attach each video to its corresponding blog post, including this one!

I’m in Love with San Francisco

It’s not my first time here.  I was no less enthralled before.  It’s different this time, though…

It’s partly the people, partly the city’s unique culture, and partly the lovely weather.  I also love that every other billboard is advertising a startup tech company I’ve never heard of.  Maybe it’s also that the tech industry has grappled itself around the fantastic San Francisco skyline (which, in my opinion, is unmatched anywhere else in the U.S.), and the nearby cities of San Jose and Palo Alto.  Regardless, this city has pulled me in and I don’t ever want to leave.

Of course, I don’t live here.  I live on the opposite coast in a city that is also beginning to rise with tech-driven economic power.  The aura that resonates from Atlanta, however, is far less attractive than that I have experienced here – just walking down the roads of this fantastic California city, I feel like I’m at home.

I have one week left to make the most of my time here until I make the sad journey “home.”  Not nearly enough time to take it all in, but just enough to entice me to return.


It’s that time of the week!

You’ve survived five days of torture, whether it be work or school.  You’ve made yourself a cup of coffee and have settled into your nice, comfy chair – all ready to relax and enjoy the short period of weekend solitude that awaits you.  Right?

NO, of COURSE not!  Mekanism v8 is out!

It’s been a big release for me.  3/4 of a year in the making, I’m happy it’s finally done.  There is so much in this release that there is no way I will be able to put it all in one changelog.  I’ll do my best, though.


  • Flamethrowers – deadly, hydrogen-powered, fire-shooting, ore-smelting, forest-burning pieces of steel.
  • Fusion Reactors – ultimate end-game energy production.
  • Lasers – high-powered laser beam emitters, capable of breaking blocks and cooking chickens.
  • Laser Amplifiers – control your lasers’ energy transmission and beam direction.
  • Laser Tractor Beams – store the items your lasers mine.
  • Factory Installers – upgrade machines to factories and factories to higher-tiered factories without breaking a block.
  • Gauge Droppers – quickly swap fluids and gases from machines’ GUI gauges.
  • Lithium – a brand new resource, created by evaporating Brine.
  • Hohlraums – the key to igniting Fusion Reactors.
  • Filter Upgrades – upgrade your Electric Pumps to filter out heavy water for Deuterium production.
  • Solar Neutron Activators – advanced, neutron-absorbing machinery for Tritium production.
  • Energized Induction Matrix – massive, modular, end-game, multiblock energy storage.
  • Oredictionificator – standardize a single kind of dust, ore or ingot for your resource collection.
  • Baby Skeletons – you heard me.


  • Brand-new upgrade system – upgrading never felt so good.
  • Redesigned side configuration menu – configure not only which sides items can enter, but also energy, gases and fluids.
  • Redesigned Seismic Reader GUI – now much cleaner and user-friendly thanks to Archtikz.
  • Enhanced Logistical Transporter algorithms – now much more server-friendly and work better with Bins.
  • Refactored machine recipe system – now completely optimized and more easily expandable for future additions.
  • IMC recipe API – allowing for much easier integration by other mod developers.
  • Digital Miner improvements – filter-based replace blocks, more filter-unique options, dynamic visual of the miner’s range, more user-friendly interface.
  • Teleporter redesign – now with a beautiful and advanced new interface and frequency-based teleportation, with private and public frequency networks.
  • Refactor of Salination Plant – now called Solar Evaporation Controller, much more CPU efficient, and capable of processing different resources.
  • Better NEI modules – neater, easier to interact with, and better showcasing of Mekanism recipes.
  • Better upgrade support – all processing machinery now can support upgrades, allowing for faster 5x ore processing.
  • Revamped multiblock system – all multiblocks now follow a unified framework, allowing for easier future additions and better code efficiency.
  • New multiblock features, including universal connected textures and multiblock creation animations.
  • Config-based machine disabling – server-based machine configuration to allow for disabling of certain machinery.
  • Improved sounds – machine and player-based sounds have been redesigned and improved to allow for seamless looping and better quality listening.
  • Refactored sound system – Mekanism’s sound system has been completely recoded to follow along Forge standards, meaning “sound mufflers” will now work on anything Mekanism.
  • Many more minor enhancements and additions I’m sure you will discover.

That was a mouthful.

Warning: Mekanism v8 contains some major changes that may corrupt some individual Mekanism machines or items.  Please back up your world before you update, or preferably, start a new world before playing with v8.  I will not be providing support on GitHub for transition issues.

I hope you all have as fun with v8 as I did developing it.  I can’t take all the credit, though – unpairedbracket has been an unbelievable help this release, and is the brains behind the new revamped recipe system, sound system, connected textures, lasers and Fusion Reactor.  Credit for the assets go to both my artist Archtikz and I.

Over the past few weeks, aside from finalizing this release, I’ve also been planning out what content will be going into v9.  I can’t promise it will be nearly as massive as this update was, but I have some pretty cool ideas.  I’ll keep you posted.

Have fun!

App Store Review Process – a horror story

I thought I’d write a brief post detailing my quest to submit my new Wordzie app on the iOS App Store.  This was the first time I’d ever attempted this, so I expected there to be some roughness along the way, but I was in for quite a ride.

To start off, the development process.  I will say that learning Swift was a very enjoyable endeavor; being a Java developer, the automated memory management that came with ARC made me feel right at home, and I was a fan of the simplistic syntax.  Apple’s Swift tutorials covered everything I needed to know and more!  Xcode, however, was a completely different story.  I’m not sure if Apple actually attempted to test Xcode 6 before its release, but it sure didn’t seem like it – as I started development in version 6.1, I was crashing at least eight or nine times an hour, and the syntax auto-completion only worked a fraction of the time.  It got to the point where I wrote the entire app’s server management in detail before I even began work on the app itself – and once I was finished, I stalled for as long as I could to open up Xcode again.

It wasn’t until Xcode 6.1.1 came out that I started the app’s development again – an undoubtedly more stable release, but still packed with issues.  It was a lot of fun to mess around with the storyboard, and any questions I had could easily be answered by a quick search through Stack Overflow.  It only took about three weeks of active coding to finish the first iteration of the app.  It’s all smooth and easy after that, right?

Wrong.  In fact, preparing the app for production made dealing with a buggy Xcode seem like heaven on earth.

Aside from getting all the proper certificates set up using Keychain Utility and the necessary build settings set up, it was miserable trying to get push notifications ready for release.  In fact, I’ve still yet to finalize their implementation for distribution – that will have to come at a later time.  At the time I finally managed to get my app submitted for review, I was ready to throw my MacBook Air through the window and smash the iPhone I had used for testing.  This was the start of the torturing 9 day “Waiting for Review” period where my constant refreshing of the iTunes Connect page most likely appeared to Apple as a continuous DDOS attack.  On the Friday I saw my app switch to the “In Review” state, my neighbors probably heard my victory cry from across the street; this feeling was short lived, however, as I was slapped in the face with a rejection just half an hour after with the most obvious reasoning possible: “2.1 – apps that crash will be rejected.”

WHAT?!  I had tested this app inside and out both on Xcode’s built in simulator and on my iPhone itself!  Impossible!  INCONCEIVABLE!

Well, it was obviously possible.  Off I go researching what could have gone wrong – after at least an hour of searching, I decide to load up the exact build I submitted to Apple onto my iPhone with iTunes.  Of course, as soon as I fire it up, I am faced with a crash.  Those pesky app reviewers were right, but how?  My stubbornness that usually does me harm came in handy – I needed closure.

Two hours of nail-biting research later (I was at least on page 19 of Google search results),  I come across something that seems so far out that it may actually be the cause – the Xcode “Optimization Level” build setting.  It seemed that this setting was different for debug and distribution purposes.  I quickly open up Xcode and change my scheme to match distribution, and am faced with the EXACT same crash on the simulator.  Brilliant.

It has now been nine days since I resubmitted the app with the working optimization level (which in my case was none), and right on queue, it’s now showing up as “In Review” on iTunes Connect.  I hope I get lucky this time around, but I have a lingering feeling that I’m going to be faced with another rejection.  Perhaps it’s just PADSD – post app-development stress disorder.  I don’t know what to think anymore.

Hopefully this post comes in handy for someone having the same issues I had.  I’ll post again once the app is finally accepted.

Oh, also, I haven’t forgotten about Mekanism, nor the v8 release.  I should be getting back on that within the next few weeks.


Here in the U.S., junior year is a pretty packed year.

It’s the year that you stack as many commitments into your schedule as you can in order to make a good impression on universities.  Even though I disagree with this routine, it is widely accepted as the way to get into a good college.  On top of this, you are expected to maintain a challenging course load packed to the brim with AP courses, do well on both your finals and your AP exams, and hold a solid GPA.  And even more, standardized testing (SATs, ACTs) are thrown at you along with gruesome hours of studying test-taking strategies and vocabulary.  It’s not fun!

You can probably now see the reason I haven’t been too active lately.  I’ve set my standards pretty high for my college selection, and the consequences of doing so are attacking me from all angles.  I’m pulling through, however – I should at least be done with the evil standardized tests by November.

Aside from this, I’ve been keeping a notebook with me that I’ve been writing ideas in.  Ideas not only for Mekanism, but also for my almost-complete PeerChess app, and for a social networking project I’m working on with a partner.  I’ve been warming myself up for these things both by prepping to become Java certified and also by developing little games.  I made pong the other day and had my friend record the sound effects – it’s pretty funny.

If you’re reading this, however, you’re probably most interested in Mekanism.  That’s understandable, and I have some plans and content in the works that should make you happy.  I’ll plan on making an update later with some sneak peeks.

A Long-Awaited Release

Hey all.  v7 has been pushed.

After many months of planning, implementing, and fixing (oh, the fixing), I performed the great merge of 320 commits into the master branch.  I hope you enjoy the:

  • 1.7.10 update, which involved a complete rewrite of the networking code.
  • Efficiency improvements, which should allow Mekanism to perform much faster on both clients and servers.
  • Portable Tanks, which I will (hopefully) be making a video on tomorrow.
  • Filter Cards, which let you save and swap filter data of Logistical Sorters and Digital Miners.
  • Seismic Vibrator and Seismic Reader, which let you explore layers under the surface without the hassle of picking up a pickaxe.
  • Salt Blocks, which make higher-tier ore processing slightly easier (and spawn kinda like clay does).
  • Fluidic Plenisher, which is the ever-hyped “opposite of a pump.”
  • Pressurized Reaction Chamber, which will be easier to use if you have installed NEI.
  • Glow Panels, which will, quite simply, brighten (and colorize!) your day.
  • Material and Mod ID Filters, which give Digital Mining and Logistical Sorting entirely new experiences.
  • Plastic Decoration Blocks, which I promise won’t pollute your oceans!

There’s a lot more to this update as well, but I’ll let you see it for yourself.  In the meantime, I’m busy coding flamethrowers for Mekanism v8.

Signing off.

The Fixing of Bugs

This week has been a week of fixes (and a little content as well).

Last week I mentioned that there were two main caveats of the current Mekanism 1.7 build – the first being the strange rendering of cables, and the second being the temporary removal of NEI.  Both of these issues ended up turning into hours of troubleshooting for me, which I will detail below.

Strange Rendering of Cables

Look at this.

That doesn’t look right, does it?  Something is…off.  Like the entire model is inside out.  Or like the textures are all flipped.  Yeah, it turns out this is a known issue in 1.7.2, and was fixed in 1.7.4 (like I mentioned before).

Anyway, I spoke to ChickenBones about this, and we ended up finding a workaround that involved using his library to take a two faced copy of the model and render both at the same time.  Not very efficient, but it works for now.

Removal of NEI

There’s a bit more too this than “it wasn’t ready yet.”  I wasn’t able to get the build script to run properly with the latest Forge and NEI installed, so I was putting this off until I updated.

Well, upon updating Forge, the script failed, stating that it was unable to reference some classes that were added with the new simpleimpl Netty wrapper system.  After troubleshooting on the #ForgeGradle IRC channel for a solid two hours or so, I was about ready to give up.  That’s when I realized that the log only was spitting out this error for 8 out of my 26 packet classes, and I found that there was a pattern – the error only occurred on my packet classes that had enums nested inside.  In other words, I found a bug with the javac compiler.  Probably the strangest issue I’ve ever encountered, and I’m going to report it to Oracle as soon as I get a chance.  I fixed the issue by taking the enums out of the nested classes.

With the fixes of these two issues, 1.7 is now technically more stable than the current 1.6 branch – this means that a release will be pretty soon.  I also have a few new features in the works :)

Hope you all are enjoying the summer, I sure am.

The Art of Updating

It’s been almost four months since my last post here.  I’m actually kind of disappointed in myself.

As most of you all know, Forge has been updated to 1.7.2 for quite some time now, and ChickenBones managed to update NEI, Forge Multipart and his other libraries as well.  Apparently 1.7.10 is already on the way, however, which means quite a bit of work is still to be done.  I seriously am debating whether or not it’s worth it to update to 1.7 at all.

Well, debated.  I decided to update anyway.

I just fixed the Jenkins server, so a working Mekanism build for 1.7.2 has been pushed to all premium users.  There are currently two major issues with the version – the first being strange rendering of cables (which is actually fixed in Minecraft 1.7.4), and the second being the temporary removal of the NEI module until I fix it.  I plan on having a recommended 1.7 build pushed out once Forge decides to update to the latest Minecraft version (which may be 1.7.11 pretty soon).

Aside from 1.7 news, I have also just pushed the final release for 1.6.4 – Mekanism v6.0.5 – which includes all the fixes present in the development branch (as well as a few additional performance enhancements).  It is the new recommended build and is available now on the download page.


Issues with v6

Thanks to all of you for a successful release – I’ve had record download counts over the past few days.

There have been quite a few issues with this update, though, some being transition issues and others being outright bugs.  I’m working my best to clear out the brunt of the issues on my end, but there’s really not much I can do in terms of transitioning.  I thought I’d make a blog post that goes over all the primary changes.

  • All transmitters – Universal Cables, Mechanical Pipes, Logistical Transporters and Pressurized Tubes – will disappear.  This is due to the recoding of the transmitter system to work with Forge Multipart (FMP).
  • Electrolytic Separators will disappear. This has needed to happen for a while – they have been merged into the core Mekanism module.
  • Clumps, Ingots, Dirty Dusts, and Dusts will screw up. As pointed out by Hephinator, all of these items had unnecessary -256 shifts on their IDs. The v6 update removes this shift, meaning any of these items you had will suddenly have different IDs.  This can be fixed by bumping up the IDs of the items in the config file by 256.
  • FMP is now required, and will auto-download.
  • MekanismInduction has been removed and is no longer supported. If you used any of the induction features, you may download Calclavia’s version.

Aside from this, make sure you’ve cleared out any conflicts with the other items v6 introduces.  I hope this is helpful to some of you, and I’m sorry I didn’t make this sooner!

Mekanism v6

…has been released.

Yes, it’s true.  After months and months of development, testing, and stressing of new features, the day has come.  Those on the #mekanism IRC channel got to witness the great cluster of over 500 commits stream over the chat log.

With the update, Mekanism now has an official wiki which is being hosted through IndieWikis.  This website and the build server is also now being generously hosted through Mastergalen, IndieWikis’ founder.

Some of you have probably experienced issues with the build server over the past day or two.  This is completely my fault and is due to the great move to the new host.  Clearing up a few confusions:

  • Mekanism is, and will remain, free.  Several of you thought I was going to begin charging for new releases since the main download links led to a login page on the build server.  This was due to an issue with permissions, and has since been fixed.
  • Mekanism’s primary build server is going to remain open.  I was considering locking down the main Jenkins build server and requiring users to go through this site’s download page, but I changed my mind.  If you prefer Jenkins, you can use Jenkins :)
  • Development builds will be closed in the next few days.  This is for several reasons, specifically that I do not want bug reports to pop up from non-testers who encounter issues with knowingly unstable builds.  After all, without restricted beta access there would be no hype with the coming of new features! However, once it goes private, primary testers (you know who you are) will be given access.  Users with premium memberships will still be able to access the dev builds.
  • Mekanism v7 is already in the works.  Yes, you heard me right.

If you have any questions or concerns regarding this release, feel free to leave me a PM over IRC or pass me an email.  All bug reports go straight to GitHub.

Enjoy, and let me know what contraptions you come up with :)