{"articles":[{"content":"With this latest commit, I've completed all of my goals for an MVP product:\n\n1) A user can login to their own account\n2) Night sky observations can be saved, edited, deleted, and displayed across multiple sessions\n3) The catalog of celestial objects to choose from is pulled from a real dataset stored in a database\n\nThere really isn't too much technical detail to go into with this latest commit. The addition of the [UpdateObservation endpoint](https://github.com/atsign/starlog/commit/176e295d3effd26e21f132797fabcd3e1b7578b9#diff-532a769d3a44423c166065b97b7a772aa7cbe8a179e84e2e99ef9378a09fee97) was pretty straightforward after all of the other endpoint work. It follows a pattern pretty similar to the delete endpoint.\n\n\nThis commit also includes some minor refactoring. In my previous post I mentioned that I wanted to move the client-side HTTP calls to their own file, so I created [observationHttpService.ts](https://github.com/atsign/starlog/commit/176e295d3effd26e21f132797fabcd3e1b7578b9#diff-3b95a526ed23272fb479848ee987c0098452d6291c27bc53650fb6ebf0759572). The observation store now references this service, instead of having all those fetches mixed in with the state management logic.\n\nWith the MVP released to production, it's time to focus my future efforts on tackling some tech debt and improving the user interface.\n","metadata":{"title":"MVP Wrap-Up","date":"2021-11-12T05:00:00.000Z","slug":"mvp-wrap-up","githubUrl":"https://github.com/atsign/starlog/tree/176e295d3effd26e21f132797fabcd3e1b7578b9"}},{"content":"\nI got sidetracked by some other projects this month, but I was able to knock out the C and D on my Observation CRUD checklist recently. I ran into a couple unanticipated hurdles along the way.\n\nI was wrong about one of my assumptions for CosmosDB. I figured a call to the Cosmos client container's `CreateItemAsync` method would automatically add an ID to the record, since (if I recall correctly) the data import for the Celestial Objects did that. I got an error when trying to insert records without the ID set though, so now I'm manually adding an ID in the repository class right before the item gets saved. I also had to return the new ID from the method so it can be referenced in the client app.\n\n```C#\npublic async Task AddItemAsync(TEntity item) where TEntity : Entity\n{\n item.Id = Guid.NewGuid().ToString();\n var result = await _container.CreateItemAsync(item);\n return result?.Resource.Id;\n}\n```\n\nImplementing the delete functionality was pretty straightforward. One security concern I had to address was how any logged-in user could pass a known item ID to the API and delete a record, regardless of whether it was one they created. I added some logic in the service layer to first fetch the item by its ID _and_ the logged-in user's ID.\n\n```C#\npublic async Task DeleteObservationForUserAsync(string observationId, string userId)\n{\n bool deleted = false;\n var observation = await GetObservationForUserByIdAsync(userId, observationId);\n\n if (observation != null)\n {\n await _repository.DeleteItemAsync(_mapper.Map(observation));\n deleted = true;\n }\n\n return deleted;\n}\n```\n\nSetting the user's ID is handled in the [Function endpoint itself](https://github.com/atsign/starlog/blob/ce7a0b09b9454199d52f4096bf2b344797134c75/api/Functions/DeleteObservation.cs), so it should be pretty tough to spoof from the client.\n\nIn this latest commit I also included a fix for a bug concerning the order of observations in the observation list. Before, I was using a Javascript Map data structure for a view model of the observations. That didn't make it as easy to sort the dates when they get added in different orders, though. Instead I switched to using a standard Javascript object with date strings as keys, and create a sorted array of just its keys to iterate through in the template.\n\n```TypeScript\ninterface ObservationsViewModel {\n [date: string]: ObservationModel[]\n};\n\nfunction mapObservationsToViewModel(observations: ObservationModel[]): ObservationsViewModel {\n const observationMap: ObservationsViewModel = {};\n observations.map(observation => {\n const dateKey: string = observation.dateTime.toISOString().split('T')[0];\n if (observationMap[dateKey]) {\n observationMap[dateKey].push(observation);\n } else {\n observationMap[dateKey] = [observation];\n }\n });\n return observationMap;\n}\n```\n\n```Svelte\n{#each Object.keys(observationsViewModel).sort((a, b) => b > a ? 1 : -1) as date}\n\n

{dateFormatter.format(observationsViewModel[date][0].dateTime)}

\n {#each observationsViewModel[date] as observation}\n \n {/each}\n\n```\n\nIn the client app code, the calls to the server to add and delete observations are currently included in the [observationStore.ts file](https://github.com/atsign/starlog/blob/ce7a0b09b9454199d52f4096bf2b344797134c75/src/lib/stores/observationStore.ts). I don't really like mixing those concerns, though, so I'm planning on moving those out to a separate service class in the TypeScript. I'm planning on including that in my next commit along with the final piece of my MVP CRUD app puzzle: updating observations! \n","metadata":{"title":"Creating and Deleting","date":"2021-10-31T05:00:00.000Z","slug":"adding-and-deleting","githubUrl":"https://github.com/atsign/starlog/tree/ce7a0b09b9454199d52f4096bf2b344797134c75"}},{"content":"\nI've now got a full vertical slice for retrieving a user's observations from CosmosDB and pulling them into the Svelte observation store. I was able to make a few improvements to the app's architecture along the way.\n\nI simply could not let the AutoMapper configuration continue taking up space directly in the Azure Function code. I moved mapper configuration to its own extension method and configured DI to inject an IMapper instance for use where it's needed.\n\n```C#\npublic static void AddMapperConfigurations(this IServiceCollection services)\n{\n services.AddSingleton(serviceProvider => {\n var cfg = new MapperConfiguration(cfg => {\n cfg.CreateMap()\n .ReverseMap();\n cfg.AddCelestialObjectMapperConfiguration();\n });\n\n return cfg.CreateMapper();\n });\n}\n```\n\nMore complicated mapping configurations, [like the one for Celestial Objects](https://github.com/atsign/starlog/blob/44df0e3a5edccfc9b4b8e2cce1baee8597aac7d4/api/Extensions/MapperConfigurations/CelestialObjectMapperConfiguration.cs), can live in their own files. I've seen mapping configuration files grow to unreasonable sizes, so I like to break them up when it makes sense.\n\nOne challenge I had to solve for was retrieving the user's ID from within the Azure function. I repurposed some [example code from Microsoft's documentation](https://docs.microsoft.com/en-us/azure/static-web-apps/user-information?tabs=csharp) for retrieving the user's claims principal. Azure Static Web Apps adds this data under the `x-ms-client-principal` header from the edge node when a logged-in user makes a request to a Function endpoint. The [UserExtensions](https://github.com/atsign/starlog/blob/44df0e3a5edccfc9b4b8e2cce1baee8597aac7d4/api/Extensions/UserExtensions.cs) class has methods for retrieving this data and parsing the User's ID from it.\n\nAnother improvement I made in this merge was to move repository calls [(remember them from the last post?)](/starlog-blog/celestial-searches-revisited) to their own services. This allows me to move a bit more logic out of the Function endpoint code itself. For example, constructing the Celestial Object query definition, calling the repository, and mapping the results have all been moved to a service method.\n\n```C#\npublic async Task> GetCelestialObjectsBySearchTermAsync(string searchTerm)\n{\n var queryDef = new QueryDefinition(Constants.QueryStrings.GetCelestialObjectsBySearchTerm)\n .WithParameter(\"@term\", searchTerm);\n\n var items = await _celestialObjectRepository.GetItemsAsync(queryDef);\n\n List results\n = items.Select(item => _mapper.Map(item)).ToList();\n\n return results;\n}\n```\n\nTurning client side, this latest merge adds some code to the [observation store](https://github.com/atsign/starlog/blob/44df0e3a5edccfc9b4b8e2cce1baee8597aac7d4/src/lib/stores/observationStore.ts) to fetch the user's observations on page load and set a loading indicator when a server call is in progress.\n\n```TypeScript\nexport const isLoading = readable(true, (set: Subscriber) => {\n _setIsLoading = set;\n});\n\nexport class ObservationStore implements IObservationStore {\n constructor() {\n _setIsLoading(true);\n\n fetch(`/api/Observations`)\n .then(result => result.json())\n .then((observations: ObservationModel[]) => {\n this._store.set(observations.map(this.reviveDate));\n })\n .finally(() => _setIsLoading(false));\n }\n\n /* class definition continues... */\n}\n```\n\nThat's one vertical slice for complete Observation CRUD operations. Next up, I'll tackle inserting new observations.","metadata":{"title":"The Vertical Slice","subtitle":"One down, three to go","date":"2021-10-05T05:00:00.000Z","slug":"the-vertical-slice","githubUrl":"https://github.com/atsign/starlog/tree/44df0e3a5edccfc9b4b8e2cce1baee8597aac7d4"}},{"content":"It's never quite sat well with me how \"cowboy-coded\" the Celestial Objects Search Function was, as seen in [this previous commit of the code](https://github.com/atsign/starlog/blob/b8470b9881c56b24a8734417315830592869c6bb/api/CelestialObjectsFunction.cs). There was SQL just hanging out there with all the other code:\n\n```c#\nstring searchTerm = ((string)req.Query[\"search\"])?.ToUpper();\nstring queryString = \"SELECT TOP 5 * FROM c WHERE CONTAINS(UPPER(c.Name), @term) OR CONTAINS(UPPER(c[\\\"Common names\\\"]), @term)\";\n\nQueryDefinition queryDef = new QueryDefinition(queryString)\n .WithParameter(\"@term\", searchTerm);\n```\n\n...plenty of magic strings to go around...\n```c#\nprivate static string URL = Environment.GetEnvironmentVariable(\"AzureCosmosEndpoint\");\nprivate static string KEY = Environment.GetEnvironmentVariable(\"AzureCosmosKey\");\n// ...\nvar iterator = cosmosClient\n .GetDatabase(\"StarLog\")\n .GetContainer(\"CelestialObjects\")\n .GetItemQueryIterator(queryDef);\n```\n\n...and a bunch of CosmosDB boilerplate that wasn't DRY...\n```C#\nList results = new List();\nwhile(iterator.HasMoreResults)\n{\n var result = await iterator.ReadNextAsync();\n var mapper = _mapperConfig.CreateMapper();\n foreach(var item in result.Resource)\n {\n results.Add(mapper.Map(item));\n }\n}\n```\n\nJust nasty!\n\nI wanted to clean some of this code up before I started sinking my teeth into saving the user's observations. Dependency injection can be used for configuration values. A repository pattern can be used for abstracting away data access concerns. And most importantly, these kinds of changes can make unit testing and test-driven development way more feasible.\n\nI used [a couple](https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app/tree/main/src) [Azure code samples](https://github.com/Azure-Samples/PartitionedRepository) as a guide to how I might want to lay things out. I ended up with sort of a hybrid approach between these two samples.\n\nI've got a [CosmosDb Repository factory](https://github.com/atsign/starlog/blob/248eff99c137258e7aaf18e6d02594c673d95c71/api/Data/CosmosDbRepositoryFactory.cs) that uses dependency injection for the `CosmosClient` and database config options...\n\n```C#\npublic CosmosDbRepositoryFactory(\n IOptions cosmosDbOptions,\n CosmosClient client)\n{\n _databaseName = cosmosDbOptions.Value?.DatabaseName\n ?? throw new ArgumentException(nameof(CosmosDbOptions.DatabaseName));\n \n _client = client;\n}\n```\n\n...which returns an instance of the [CosmosDB Repository class](https://github.com/atsign/starlog/blob/248eff99c137258e7aaf18e6d02594c673d95c71/api/Data/CosmosDbRepository.cs) for common data operations:\n```C#\npublic class CosmosDbRepository : ICosmosDbRepository\n{\n private Container _container;\n\n public CosmosDbRepository(\n CosmosClient dbClient,\n string databaseName,\n string containerName)\n {\n _container = dbClient.GetContainer(databaseName, containerName);\n }\n\n // Data read/write/delete methods below...\n```\n\nAll of the code for these classes was written against [unit tests first](https://github.com/atsign/starlog/tree/248eff99c137258e7aaf18e6d02594c673d95c71/ApiTests/Data), which was a nice return to form for me. Test-driven development is my default mode for the kind of API work I do at my day job, and it was nice to finally bring some TDD to this project.\n\nI've got a clear runway now for creating API endpoints for CRUD operations on the Observation data. With a test project started, some nice reusable data repository classes, and dependency injection in full swing, I should be able to start writing some tests for the next phase of the project.\n","metadata":{"title":"Celestial Searches Revisited","subtitle":"Using TDD to make data access clean and DRY","date":"2021-09-23T05:00:00.000Z","slug":"celestial-searches-revisited","githubUrl":"https://github.com/atsign/starlog/tree/248eff99c137258e7aaf18e6d02594c673d95c71"}},{"content":"Another reason I'm glad I went with Azure Static Web Apps: authentication couldn't be easier. Out of the box, I was able to set up a [login page](https://starlog.aiafrate.com/login) with GitHub and Twitter auth providers. I'd like to work with custom providers down the road, but this is a good start. SWA has built-in URLs to handle authenticating with those providers, as well as an endpoint to retrieve the logged-in user's claims and roles.\n\nThe most challenging piece of the puzzle had less to do with authentication and more to do with handling the post-login and post-logout redirect URLs. You can specify a URL to redirect to as a query parameter in your request to the auth provider, but it has to be fully qualified. I could have hard-coded the production URL in the code, but I'd rather have that URL pulled from an environment variable. Getting environment variables to play nice with both SvelteKit and Static Web Apps proved a bit challenging.\n\nAfter some sleuthing and some trial-and-error, I was able to get SvelteKit to pick up environment variables from a local `.env` file, though they have to be prefixed with `VITE_`. Under the hood, SvelteKit uses Vite to generate its output, and Vite has a built-in constant for accessing environment variables during compilation: `import.meta.env.VITE_FOO`, where `VITE_FOO` is defined in the `.env` file.\n\nTo get SWA to pick up the environment variable during its build, I can't use the configuration variables in Azure Portal the way I would for the Function endpoints. I had to add an `env` section to the [GitHub workflow .yml file](https://github.com/atsign/starlog/blob/0bf2271af3ba3c6b39595c297c22a46965cf8d67/.github/workflows/azure-static-web-apps-nice-sand-0829c7010.yml#L34) and add the production URL there. It would be nice to be able to set this URL to the staging URL during pull requests, but I'll have to do some more research on that.\n\nClient-side, I've added an [authentication store](https://github.com/atsign/starlog/blob/0bf2271af3ba3c6b39595c297c22a46965cf8d67/src/lib/stores/authStore.ts) that can be used to get/set the user's auth status. This works to automatically set the \"Login\" and \"Logout\" link in [the site navigation](https://github.com/atsign/starlog/blob/0bf2271af3ba3c6b39595c297c22a46965cf8d67/src/routes/__layout.svelte#L44). Svelte's built-in state management couldn't be simpler!\n\nComing up next: it's time to roll up my sleeves and start saving some of this Observation data in CosmosDB.","metadata":{"title":"Authentication","date":"2021-09-17T05:00:00.000Z","slug":"authentication","githubUrl":"https://github.com/atsign/starlog/tree/0bf2271af3ba3c6b39595c297c22a46965cf8d67"}},{"content":"To make things a little easier on myself while I work on the next phase of the project, I thought it might be wise to have a system in place to handle page layouts and routing. Svelte itself is great for building components and managing state, but I'll soon have to think about having different pages for user account management, an \"about\" page, and so forth.\n\nI've been building this portfolio site and blog with [SvelteKit](https://kit.svelte.dev), and getting more comfortable with using Svelte in that context. It was a pretty straightforward Sunday afternoon project to take the raw Svelte components I had built for the POC app and lift-and-shift them onto a blank SvelteKit project. I think I've got a bit cleaner of a folder structure now, too. The [routes](https://github.com/atsign/starlog/tree/f0231c7443de8bcb17c133504948b19fd988c9b7/src/routes) folder handles site content and layout, and the bulk of the application logic and components have been moved to the [lib](https://github.com/atsign/starlog/tree/f0231c7443de8bcb17c133504948b19fd988c9b7/src/lib) folder.\n\nI anticipated running into more issues getting things to load once I moved all the files. Aside from having to fix some red squigglies in filepath references, everything just started working as expected. I thought I'd at _least_ have issues with the Static Web Apps deployment, but that didn't skip a beat either. Fingers crossed that user authentication goes this smoothly!\n","metadata":{"title":"The SvelteKit Refactor","date":"2021-09-12T05:00:00.000Z","slug":"sveltekit-refactor","githubUrl":"https://github.com/atsign/starlog/tree/f0231c7443de8bcb17c133504948b19fd988c9b7"}},{"content":"\nWith the current state of the app, the user can now search for celestial objects in an autocomplete search box, choose the desired result, and save it with their observation data. Reaching that goal involved three distinct efforts: 1) finding a good dataset of celestial objects and storing it in a CosmosDB container, 2) implementing an Azure Function for querying that data and returning the results, and 3) implementing a Svelte component for the search UI.\n\nThe dataset I ended up using comes from [OpenNGC](https://github.com/mattiaverga/OpenNGC), an open source aggregation of different celestial object catalogs. It's raw CSV data, so I needed to convert it to JSON before migrating it to a CosmosDB container. It has pretty much all of the data for objects that I'm interested in at the moment: its positions in the sky (right ascension and declination), its official catalog name (like NGC1976), and other common names (like \"Orion Nebula\").\n\nI wrote the [Azure Function for the API endpoint](https://github.com/atsign/starlog/blob/a3d0f8d4db32549c5db57d38df7529df856e9aa6/api/CelestialObjectsFunction.cs) in C#. I went that route because it's the language I currently use the most in my day job and I'm quite comfortable with it. I considered writing it in Node.JS instead, and I might switch to Node for future Azure Functions, but that's the beauty of using Functions for the back-end—I can mix and match runtimes as I see fit! The Function queries the data's `name` field for the search term, as well as the `Common names` field.\n\n__Warning: Astronomy nerd talk incoming!__ One issue I'll need to solve for: if a user searches by Messier catalog designation, like \"M13\" or \"messier 13\", they won't get any results. That's because the dataset has a separate `m` field, whose value is just an integer corresponding to the Messier number. I'll have to either modify the query logic to account for searches like that, or modify the dataset to take the `m` value and add it to the `Common names` collection in the form of \"M13\", \"Messier 13\", etc. For a commercial product, this would be a showstopping bug. But for my purposes here, it's something I can save for a rainy day.\n\nOnce I had the Azure Function querying the CosmosDB and returning results in a form I expected, it was pretty straightforward to hook up a third-party Svelte autocomplete search component. I ended up going with one appropriately called [Simple Svelte Autocomplete](https://github.com/pstanoev/simple-svelte-autocomplete). It's a pretty simple drop-in solution in [my Observation form component](https://github.com/atsign/starlog/blob/a3d0f8d4db32549c5db57d38df7529df856e9aa6/src/ObservationForm.svelte#L73). A couple tweaks of the default settings and a couple [small style hacks](https://github.com/atsign/starlog/blob/a3d0f8d4db32549c5db57d38df7529df856e9aa6/public/global.css#L72) to get it to match the rest of the form, and I had a pretty good solution to my \"celestial object search\" problem.\n\nThe next major issues I want to tackle are user authentication and data persistence. I'm pretty certain I'll continue using CosmosDB for the data, but I'm not very familiar with what Azure has to offer in terms of authentication. My next step will be to do a little research around that.","metadata":{"title":"Celestial Searches","subtitle":"To the API and back again","date":"2021-08-29T05:00:00.000Z","slug":"celestial-searches","githubUrl":"https://github.com/atsign/starlog/tree/a3d0f8d4db32549c5db57d38df7529df856e9aa6"}},{"content":"\nI had to take a break from the StarLog project for a couple months to focus on some other things, but I recently dusted the cobwebs off the code and got back to work.\n\nAfter some brief toying with the [IBM Carbon component library for Svelte](https://carbon-svelte.vercel.app/), I decided to swap out Sveltestrap entirely. I prefer the overall variety of Carbon components, and the look and feel is more my style.\n\nIt was pretty straightforward to remove Sveltestrap references from the existing components and replace them with their Carbon counterparts. After a little tweaking, I had a redesigned app that was just as functional as the original Sveltestrap version.\n\nWith those changes in place, I'm in a good spot to shift my focus to some API integration. I'd like to start writing an Azure function to retrieve celestial object data, and tie it into an autocomplete search field on the observation form.","metadata":{"title":"The Carbon Refactor","date":"2021-08-20T05:00:00.000Z","slug":"carbon-refactor"}},{"content":"\nI now have a functioning POC that can add, edit, and delete astronomical observations—at least in the web browser, and for a single page load. And it's all happy path. If you forget to fill in a celestial object for your observation, for instance, the app will crash. But form validation can wait for a future iteration.\n\nThe POC stage has given me a good first impression of Svelte. I haven't explored all of its features yet, but I like what I've seen so far. I imagine I'll be refactoring the Observation data store as things progress and I become more familiar with the Svelte community's best practices. But so far I'm impressed by how much can be done with relatively little code.\n\nI'm already starting to second guess my decision to use Sveltestrap for the component library. The library seems a little rough around the edges, and I'm running into an issue around data binding with the datepicker input component. It may be an issue with the library itself, but could just as well be an issue with the way I'm using it. I may explore other component library options for fun. And besides, Svelte has made me pretty confident I could swap component libraries with relatively little effort.\n\nI'm happy to see something to interact with on the screen. Next I'd like to focus on replacing the select input for picking celestial objects with a more user-friendly autocomplete search box. If I can get it to talk to a database to search for celestial objects, it will be a good first step toward unifying the front and back ends.","metadata":{"title":"Proof of Concept","date":"2021-06-16T05:00:00.000Z","slug":"proof-of-concept","githubUrl":"https://github.com/atsign/starlog/tree/0d3202529e2d734dd92879d11523990d42104e3b"}},{"content":"\nMy UI-first approach to this project led me to choose an application architecture that favors quick, simple static hosting for the front-end with a serverless back-end. I considered platforms like [Netlify](https://netlify.com) and [Vercel](https://vercel.com), but Microsoft had recently released [Azure Static Web Apps](https://azure.microsoft.com/en-us/services/app-service/static/) for general availability and it caught my eye. I'm comfortable in the Microsoft ecosystem because of my day job, so SWA seemed like a natural fit. It allows me to easily fit the front-end to Azure's serverless features down the road when I need them\n\nFor the front-end JavaScript framework, I wanted to use something I'm not as familiar with—[Svelte](https://svelte.dev). Most of the UI work I do at my job (which, admittedly, has been few-and-far-between the last couple years) is in Angular. I've used other frameworks in the past, but I had been looking for an excuse to learn some Svelte for a while. It seems to address a lot of sources of frustration with other frameworks, particularly around tooling and state management.\n\nWith a JavaScript framework picked out, I started looking into potential UI component libraries. I considered a couple Material implementations for Svelte, as well as a lightweight library using the Chota CSS framework, but in the end I settled on [Sveltestrap](https://sveltestrap.js.org/?path=/story/components--get-started), a Svelte implementation of Bootstrap. It offers a nice balance of features, familiarity, and maturity in a component library.\n\nWith all of those decisions made, it was quick work to throw up a quick Hello World project in Azure.","metadata":{"title":"Laying the Foundation","date":"2021-05-24T05:00:00.000Z","slug":"laying-the-foundation","githubUrl":"https://github.com/atsign/starlog/tree/9ea4ff5402c2a94925fee6538677b6d773a18cc6"}},{"content":"\nAs mentioned in my [previous post](/starlog-blog/introduction), the app I'm going to build for this project is called StarLog. It will be a fairly simple stargazing journal, allowing the user to keep track of what they saw in the night sky, when they saw it, and any other fun details about their observations.\n\nFor a proof-of-concept app, I'm not going to be too concerned about things like user accounts and persistent data storage. I just want to be able to interact with a screen in a web browser. The UI doesn't have to be fancy, either. A simple CRUD interface will do.\n\nWhat would be considered a minimal viable product, then? To reach MVP, I'll want a user to be able to log in, save their observations to a database, and load them again in a new session. I'd also like to have a database-backed list of astronomical objects to choose from when making entries in the journal.\n\nFrom there, I could imagine the app being improved in a number of ways. Fancier UI elements, additional fields for the observations with more complex data relationships, maybe an interactive star chart that plots the locations of each entry visually across the night sky.\n\nBut that's getting a bit ahead of myself. In the meantime, I'll focus on choosing the right technology stack and start getting some code written.","metadata":{"title":"The Project Roadmap","subtitle":"From POC to MVP","date":"2021-05-19T05:00:00.000Z","slug":"project-roadmap"}},{"content":"\nSo, here's my conundrum. I'm a seasoned software engineer, but my portfolio's actually kind of out of date. I have a [day job building software for a financial services company](/resume), but I haven't worked on a public-facing product in several years. How might future employers or clients know I'm a good fit for their organization?\n\nTo help solve this problem, I decided to build a small web app from scratch, document the process, and put the source code online. I want to share my approach to problem solving, explain the roadblocks I encounter, and why I might choose one solution over another.\n\nOne of my many hobbies is backyard astronomy. For this project, I decided to build a digital \"observer's notebook\" called __StarLog__. It will be the kind of journal stargazers might use to log their observations from night to night.\n\nA simple app like this can fairly quickly go from proof-of-concept to production-ready, and be gradually enhanced with new features over time. Each step along the way is an opportunity to illustrate my approach to software engineering. I hope you'll tag along with me!\n","metadata":{"title":"Introduction","subtitle":"What is the StarLog Blog?","date":"2021-05-18T05:00:00.000Z","slug":"introduction"}}]}

The StarLog Blog

Recent posts

StarLog Links

All Posts