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!