Postman is an incredibly useful tool for testing API’s. I’ve been using it for a few years now and have found some features that make it a breeze to work with when it comes to secured API’s. It’s good for handling different environments as well.
Login and Tokens
Angular routing is pretty nifty. Going into how it works is beyond the scope of this post (and there’s plenty of resources out there doing just that), but suffice it to say if you’re working on an Angular application, you’re using Angular’s routing.
One of the things Angular’s routing does to increase performance is reusing a Component for a route that has already been instantiated. Say you have a Component, “MyComponent”, tied to a route, “/MyPath”. “MyComponent” isn’t created until the user actually navigates to the “/MyPath” route. That makes perfect sense – why instantiate a component that doesn’t need to be used yet? What’s interesting about this design, though, is how parameters factor into it. Let’s say you add a parameter to your “/MyPath” route, making the route “/MyPath/:id”. The first time the user navigates to some version of this route, let’s say “/MyPath/1”, “MyComponent” will be instantiated (with the id parameter set to 1). Then if, without leaving that route, the user changes only the parameter – for example, there’s a link in the component to go to “/MyPath/2”, “MyComponent” will not be recreated. In fact, if not handled correctly, to the user nothing will have changed. It will still look like they’re seeing the “/MyPath/1” version of “MyComponent”. Continue reading “Angular – Refreshing a Route with Parameters”
I’ve been interested in learning more about functional C#, and how it differs from the OOP style C# that I’ve been doing for years. Ed Charbeneau gave a talk on this topic at CodeMash back in January, the main lesson being how to score a poker game using C# and functional principals and the samples. In this blog entry I will be reviewing a few of the functional principals I took away from the presentation— there are many more but here’s a short list: Continue reading “Functional Programming with C#”
Yes, it is that type of blog post. I have been attending conferences for almost 20 years now in varying industries and for the most part, I truly enjoy the experience. However, there are a couple things that simply infuriate me that I keep noticing more and more frequently.
Continue reading “What really grinds my gears at conferences”
In my Observables in Parallel blog post I discussed how I’ve been moving away from Promises in favor of Observables and how to translate functionality from promise-based solutions to observable-based solutions. The aforementioned blog post discussed how to wait for multiple Observables to complete before performing some action. In that scenario all the Observables were independent of each other, meaning none of the Observables depended on the results of another.
In this blog post I’m going to discuss how to use Observables that do depend on a different Observable to complete before executing – AKA Cascading Observables. One such use case scenario for Cascading Observables is when you need to call a web service to get some data, then use that data to call another web service, all in a single operation.
Continue reading “Cascading Observables”
Every year when I go to CodeMash, I try to do a pre-compiler session on something that makes me uncomfortable or I know little about. This year, it was the Science of Great UI session presented by Mark Miller (@greatui). I am not completely lacking in artistic ability, as I can play quite a few musical instruments well, but when it comes to visual art, I am beyond deficient. I know CSS and if you give me a design I can make it happen, but to say that I do not have an eye for design is a significant understatement. Thankfully, there are folks on our team with better design taste to save me from myself.
Continue reading “CodeMash 2017: Science of Great UI Session Review”