atla5 / blog Goto Github PK

subtitle: JSON is love, JSON is life.

Background

so, there's no real reason you'd pick up on this, but a large number of my projects have a significant portion of their data stored in json, and almost all of those related to my site have tags values:

project	json files
resume	about, additional, education, experience, projects
blog	hidden in (almost) every .md entry (e.g. semantic-file-system)
FeedReader	listing of feeds in feeds.json
lib-re/crosswalk	language encodings (e.g. dc.json)

the thing is, i didn't entirely do this with the plan of having all of them displayed on my site (someday, lol). i just really love reusable data that is just data. i also didn't know much of anything about react, or how great it is at dealing with remote data.

Plans

in the future, a part of my site i've been planning for a while, will collect all of the tags in particular and display them all on one page within their given header (ideally even with their given components [v3.0]):

Tagged 'Library Science':

Blog Posts (from /atla5/blog/entries/)

• Linked Data and Enveloping Referencing
• Leveraging High Static Complexity

Projects (from /resume/projects.json)

• lib-re/dublin-core-text-parser
• lib-re/lib-name-parser
• lib-re/organon

Work Experience (from resume/experience.json)

• ITHAKA - JSTOR
• Wallace Library

Courses (from /resume/education.json)

• MUSE-340: Introduction to Archives
• MUSE-359: Cultural Informatics
• ...

Feeds (from /feedreader/feeds.json)

• Lost in the Stacks
• Cataloguing Matters
• Thingology
• ...

How

The difficulty will come with writing some sort of aggregator in each repository to surface these tags in the cleanest way possible. Since I don't want a single repository responsible for interpreting the schemas all the others (way too complex), i'll likely have to house that in each repository.

Even with this, though, I'll end up having to watch out for any changes and potentially make edits to 4-5 repositories to get it working. I'll have to think on this more.

Why

• be able to click on a single listed 'tag' and find my interests, experience, resources, and musings on a given subject
• helpful for me to find some of this content anywhere without having to search through 4-5 places
• be able to point someone (future employer) to a url containing my collected background on a given thing.
• it demonstrates the full power of keeping your data separate and clean.
• makes use of all the miscellaneous extra content on resume that i had no direct use for in exporting to pdf.
• intense exercise in data curation across distributed sources.
• i mean, come on, how cool with this be to see working across my entire corpus?

The importance of separating your cleanest possible data and its myriad export formats.

Export to formats should be done upon request and be populated by your data at that point in time. (e.g. atla5/resume). ...

Whenever possible and/or appropriate, you should store this data in json, and provide a documented API (automatically like with swagger) to it directly, so your other internal services and external consumers can permute it to their exact need.

...

tags: ["scrum", "aristotle", "philosophy", "virtue", "process", "software engineering"]

when i first began learning about scrum in school, the position of scrum master seemed superfluous, and the methodology itself appeared undirected, imprecise, and even sloppy to me. The fixation on workplace 'culture' seemed distant and almost

as i learned more about it and worked within it, however, and truly started practicing continuous integration and deployment, it has become the only way i see myself wanting to work.

--

a large part of software agility is the establishment of processes which 'bake in' testing, code quality, retrospectives (pulse checks and process improvements), planning, etc. in a way not unlike Aristotle's conception of cultivating beneficial habits of virtue in order to promote health, happiness, and character.

--

• add textual examples??

#SoftwareEngineering is a truly incredible field. that open source/access is such an infrastructural component, that understanding and contributing to it is so simple (open by default), that source control/provenance is solved. how do we share that with other human endeavors?

— Aidan S (@Aidan_KS) November 9, 2017

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Software engineering has solved, seemingly subconsciously, some of the most perplexing and ground-breaking problems in LIS, publishing, open access science, etc. partially by making (and/or realizing that) the most honorable, ethical, productive, and valuable methods the easiest, most productive, and effective paths towards affecting the change you want and creating/sharing the solutions most critical to the task at hand.

outline:

• microservices brought about a sea change over the last decade in how we architect backends

• we're experiencing the same pain points from monoliths on the front end that triggered the backend change

  • large amounts of coupling leading to required communication/coordination of deploys
  • becoming locked into using the same stack for all new projects, regardless of composition
  • resulting decrease in team autonomy and agility

• being stuck in the same repository/stack using pre-built middleware has a detrimental effect on developers ....

  • leads to lack of knowledge about backend services and how to use them in different environments
  • breeds laziness in figuring out how the ecosystem itself works
  • over-reliance on existing code (not being cognizant of how to re-create it)
  • tendency towards patching holes in architecture in the singular consumer instead of the service itself (i.e perhaps a major service in your ecosystem is only used by the front-end, and you patch a vulnerability in just the BFF).
  • while these are controllable by a virtuous developer, the pitfalls and temptations are there

• ... and creates a disconnect between front-end and backend devs and projects, even within the same team.

conclusion:

• while the backend has become distributed, agile, scale-able, replaceable, and allows for polyglot optimization and large amounts of freedom
• BFF frontends create static, coupled environments that demand conformity and coordination while preventing the use of the best technology for the job.

resources:

• ‘official’ website with some super handy diagrams: https://micro-frontends.org/
• nice collection of slides with good info and diagrams: https://speakerdeck.com/naltatis/micro-frontends-building-a-modern-webapp-with-multiple-teams
• easy intro [medium article] https://medium.com/@tomsoderlund/micro-frontends-a-microservice-approach-to-front-end-web-development-f325ebdadc16
• differences in front and backend microservices architectures [video] https://www.youtube.com/watch?v=pU1gXA0rfwc
• presentation describing how one team broke their front-end monolith up and what kind of problems they were seeing before the switch (especially near 11 minutes) [video] https://www.youtube.com/watch?v=vCzTK4XPfX8

core qualities

• essentialization (within a given context): determining what is centrally important/at hand
• breaking a complex problem into solvable components
• intelligence/quickness: how adept they are at working around a problem
• discernment: evaluating priority and timescale
• communication: externalizing and transferring their thoughts/intentions/questions
• personability/soft skills: including other axes and planes of consideration into their thinking (how do you do this with continuous integration, QA, delivering business value)
• incorporation of design principles: repeatability, importance of quality and architecture over a hacked solution

general concepts

• keep the questions very abstract and interpretable.
  • see if they'll seek clarification and context for their response (a key element in working with others and not over- or under- engineering a problem)
  • let them determine the importance and gleam from their answers their evaluations, mode of problem solving, etc.
  • let them guess at intention and fill out the core motivations for the question (what do they view as important and/or what do they expect from you)
• keep away from expected, rote, memorization-based questions:
  • break out of the context of an interrogation or exam to have a meaningful interaction with what may be a future coworker
  • test their ability to think and not to remember (ensure that you're measuring their active, conscious mind and not their ability to reproduce or regurgitate answers)
  • demonstrate your care for them as an individual/human being and not just as a "candidate"
• focus on more than their technical qualifications
  • how will they interact with other roles in the organization? can they separate the technical and business value?
  • how will they organize and deliver their work? will they spend silo-ed days on the wrong problem when they could solve and deliver a hefty amount of the value quicker and then iterate?
  • how will they modify their implementation to the context and existing framework?
  • will they be an enjoyable and productive individual who others will enjoy working with?

1) Why are you a software engineer?

what this captures

• core motivations and the ability to articulate them
• ability to essentialize: reducing large, systematic concepts into a brief response without doing damage to the complexity or importance
• compartmentalizing a problem into various facets and describing how they interact
• ability to particularize/communicate to a particular audience or in an established context
• introspection/self-awareness: does this person have the capacity to locate the relevant personal aspects of their life and why they are important to mention at this place/time
• spark: is this person motivated and passionate about what they do and what it can do at your company?

why this is meaningful/valuable

• capacity to identify core motivations and deep answers to a simple question in a short amount of time
• ability to essentialize a very large concept into a short response
• tailor their answer to the person they're talking to in the context that individual understands
• calms the individual and gets them conversing in a more personal, lower stressed tone (non-technical, non-combative

my 'best' answer

• to produce and deliver value by solving complex problems in repeatable and impactful ways that have a meaningful effect on an important sector of human life.

2) Why are you here? (i.e. do you want to work for this company)

what this captures

• competency for explaining intrinsic and extrinsic value to an invested party on the spot from your end (what you get) and their's (what they get)
• preparation for understanding core business functions/missional goals
  • how highly do they value your company in particular among the many they've applied to?
  • how seriously are they taking
  • to what extent do they consider missional goals/business context in their working life? do they only care about technology or location or
• central motivations and whether they are potentially fleeting or entirely selfish
  • will this person leave as soon as they get a better offer?
  • will they be motivated and personally invested in what the company is trying to accomplish?
  • do they have the passion to motivate creative solutions and paths outside of what they're directly handed?

why this is meaningful

• tie current actions to long-term value
• ...

my 'best' answer

• missional goals of the institution and why they exist
• how delivering value in current trajectory has a larger impact on a given context and why that context is important.

3) What is the shortest path between these two points?

present them with a basic maze with two points on alternate corners and no additional rules.

what this captures

• ability to ask meaningful questions about requirements/content (requirements, MVP) before diving into solutions
• elucidating and ferreting out assumptions/artificially imposed restrictions on how it "must" be solved
• how to find the MVP within a given context to deliver value as quickly as possible
• technical capacity (if they have to find the general solution, how do they architect its solution)
• ability to break out of perceived or borrowed contexts to look at the specific, actual constraints of a given problem

why this is meaningful

• achieving MVP
• assumptions of how you must implement something are some of the highest cost disconnects between over-engineering idyllic systems and delivering value
• ability to situate the technical problem within a business context

my 'best' answer

• clarify the lack of additional constraints in the question (this is the only criterion)
• draw a line directly connecting the two dots without any attention paid to the walls
• ask questions about:
  • perspective and amount of knowledge you have (are you first person as the dot or do you have the overhead view of the entire path)
  • repeatability and context of the problem (solving for all cases or just the one at hand? can you cache? are parts of the maze exactly the same or in components)?
  • what value does this deliver over what time scale? (release the first solution and then solve the general case)
  • how does this maze manifest in real life? are there repeatable segments or necessary intermediate segments? can you eliminate entire sections of the maze to make the problem simpler?

extending the <data> tag:

• via HTML Imports (e.g. src="")
• cache-expiration (e.g. cache="10m")