You can practically hear the synth music when you look at these neon curves.
But it is still my baby! This was an assignment to get into shaders – I’m excited for the potential that working with a pattern brings but this project was a doozy. Lots of work to get both the vertex and fragment shader working but I *do* feel like I understand the concepts better.
Tip #1 for OpenGL shaders – don’t use a Mac.
My husband and I have recently moved to British Columbia from the Seattle area. The move has been amazing so far – we get to stay in the beautiful PNW and get to be closer to his family in Vancouver. The only detractor has been that I’m unable to take advantage of the job offer that resulted from my internship at Expedia. As I mentioned in an earlier blog post, my experience at Expedia was wonderful and I’m certainly saddened by the fact that I can’t just roll into a good job in January.
Instead, I’m back on the hunt for a job in software development. In previous careers, I loved interviewing – I can ace a behavioral interview in my sleep (thank you acting training!). I’ve really struggled with technical interviews, though. On a few occasions I have completely choked – I’ve reached a dead end in a coding challenge and I could feel the panic shutting down my ability to think. Meditating before interviews helped significantly and saying “I need a minute to think” and taking a few moments to gather myself when I have gotten stuck have helped even more.
I try to keep it low pressure for myself and even have fun with the process – the interviewer is an important part of this – but I also know preparation is a big part of preventing future choking. My goal is not to memorize solutions but really to build my confidence and reinforce language syntax so basic things don’t hang me up. So, my plan for once the chaos of my capstone project dies down is to do the following:
- Complete a LeetCode Medium/Hard problem once a day
- Take the CodeSignal General Coding Assessment once a week
- Start work on a personal project to keep my skills sharp (and remind me of why I love to code!)
This video shows my first foray into lighting in 3d graphics – combined with the texturing (in this case a moss texture on the largest sphere) I feel like I’m getting much closer to something you might see in a video game!
I’m sure most of us aspire to use a Test-Driven Development approach to our coding – it forces clarity on requirement definition and can be invaluable in supporting alignment between team members/different services for an app. This would typically take the form of unit testing but, to test the full functionality of an API endpoint it requires a slightly different set of tools.
As my capstone team continues work on our own API we want to make sure we hand off a complete set of tools to our industry partner at the end of the project – including an API test suite. So – which tool to use? Through our own professional and academic experiences with these tools, we are currently deciding between two tools – Postman and Swagger.
Postman offers a friendly UI that can be completely separate from the app repository/deployment. Postman allows you to:
- import both an environment and a test suite
- define multiple tests for the same endpoint
- set local or environmental variables – both before and after calls
- run an entire suite of tests with a single click
Alternatively, Swagger is more closely integrated with the code itself. Swagger allows you to:
- define parameters, descriptions, and defaults using decorators directly within the code
- perform manual testing in a user-friendly GUI where both the response and request are clearly laid out, side by side
Both tools offer automated testing tools – helpful for integration or reliability testing – and have similar price points. Assuming that running the app (or accessing its deployment) is trivial – Swagger offers a very friendly UI and makes it easy to incorporate Swagger documentation into coding comments and code review. It does require a “home” for the GUI but can be nicely incorporated into a team’s wiki. Postman feels like a more compartmentalized option – assuming the users have some familiarity with Postman, importing the environment and test collection is easy.
For my team’s use case – where we will not be maintaining the project in the long-term – Postman seems like the logical choice since we don’t know how our industry partner will ultimately deploy the app and Postman’s environment configurations are easily changed.
This week’s graphics assignment was about binding a texture to an object and then (intentionally!) distorting it. Lava ball coming right up.
Here we go, ya’ll – time to learn another language – C# /.Net. I’m currently working on a project where the legacy code is written in C# and, in a moment of personal growth, I decided to learn another new language to write the needed API endpoints rather than trying to use Python.NET.
I decided to go this route for a few reasons: 1) My love for Python is a personal preference, not a business need; 2) By now I know that, every time you add a layer of complexity, you increase the difficulty of troubleshooting exponentially. The project in question is a web app so I’m not too concerned with .NET’s capability for cross-platform support or security features but the documents and developer blogs are convincing regarding its scalability – reportedly it is easy to add more servers to help distribute load. Our plan for deployment doesn’t have me too worried about scalability but this gives some piece of mind.
The big concern for me will be compatibility with some of the tools we have to use – Open Street Maps and a TBD frontend tool for map display. These things are notoriously slow to load and display and lack of speed could kill the desirability of the product. I also want to make sure we are keeping things as modular as possible – our current requirements include relatively basic features and no use of real-time data so, if it is successful, I think it is likely that more interactivity and data specificity will be demanded.
This week I learned more about transformations in OpenGL and animated the spinning of the propellers you see above. I used a Cessna model from free3d.com and gluSphere() to create the sphere. Really cool to better understand the steps that underpin animation.
This is my first foray into computer graphics and using OpenGL. The assignment was to use at least 5 colors and 100 vertices – I procedurally generated each set of triangles and their accompanying “base”/square. I didn’t really have a subject in mind but some options are: spikes on a colorful iguana’s back, wedge-shaped post-it note pads, and multiple projectors in a row. Looking forward to diving into lighting and textures next!
Getting back into the workplace after (almost) 2 years of school and ??? years of pandemic this summer was surreal and satisfying. I joined the Infrastructure Automation team at Expedia for a 10 week software development internship. The team is primarily responsible for provisioning Virtual Machines and infrastructure assets via code and the main focus of the summer was getting ready to launch a new internal tool that would allow Expedians to spin up and manage their own VMs according to their specifications – OS, server location, server size.
For the tech-stack curious – the platform used Stackstorm (written in Python and YAQL), Java Spring, Mongo, and React. Using Stackstorm, in particular, was an interesting experience. Workflows are managed from a YAQL file that forces you to define inputs, global variables, and outputs at the top of the file and some. . . interesting handling of conditional branching. Unlike absolutely every other language in existence*, once a conditional block was hit, it would execute whatever it contained AND still check the state/variable/whatever against all the other following conditional statements.
The documentation for Stackstorm is quite good but this point wasn’t entirely clear (even for my teammates who had been using it for years). As with most things, once you know the quirk, the possibility of hitting multiple conditions can be helpful (even if those statements end up being a little Frankenstein’s monster-ish). I’m still not sure what’s happening under the hood with this branching – i.e. is it more of a JS promise situation or like child-processes. We (I) may never know.
Outside of syntax, Stackstorm comes with some nice unexpected features like automatic generation of workflow visualization – really helpful for wrapping your head around any spaghetti branching you may have created and great for communicating between team members.
4 out of 5 stars, would use Stackstorm again (1 star taken off for triggering memories of using Assembly).
Tech aside, the team was amazing – friendly, funny, and helpful. I don’t think I’ve ever seen a dev team with this strong of communication skills. The overall company culture at Expedia seems great, too. My view was short and full of intern hand-holding but the desire for inclusivity seems sincere and the work/life balance appears to be great for most people there.
*Please don’t factcheck this