paphillips

The bizarre thing was that the page source at that time had almost nothing except some odd javascript to build a "508 Daily Report" table of Jira tickets or some nonsense.

The AMF project [1] can be used to parse and transform to/from RAML, OpenAPI, GraphQL, and json schema. Code generation to languages of choice can be bolted on from there.

I'm using this approach to define canonical data models. Subsequent code generation scaffolds internal application integration apis, master data management (MDM) entities, and SQL/OLAP artifacts for ETL / BI purposes.

This approach keeps overall end-to-end data architecture consistent, in sync, and versioned under source control. Additionally, flat types as required by relational systems are re-used and composed into nested complex types more appropriate for apis. Metadata is layered on as needed to refine the models for system-specific needs, for example to add user-facing field groups, descriptions, and formats for BI datasets, sensitivity levels and other data security controls, business rule definitions for MDM, etc.

XL Construction is an award-winning Northern California general contractor/builder, consistently voted as one of the best places to work in the Bay Area by the San Francisco Business Times / Silicon Valley Business Journal, and is ranked as the fourth largest GC in the Bay Area as of last month.

We are in the early stages of executing a long-term enterprise-wide data strategy and this role is key.

XL is seeking an individual with 5 years of application integration development experience with Mulesoft or similar, and a commitment to software engineering best practices in a team environment. We run a modern suite of applications so you won't have to fight crusty, antiquated, and temperamental APIs and can better enjoy the satisfaction of getting information flowing.

I am XL's interim data architect and look forward building great things together.

Please review the full job posting [0] and apply there if you are the one. Reply here if you'd like to give me a head's up.

I had been making the SV surplus store rounds at least once a month - Halted (HSC), Weird Stuff, Excess Solutions, etc (plus the Fry's swap meet). Those nicely furnished my garage workspace with industrial-quality furniture, equipment, and other random bits, but sadly all have closed.

Nowadays I am down to one SV store on my short list that is still around, and they only sell office furniture and electronics workstations - neither of which I can use any more of. I'm hoping these types of stores are a trailing economic indicator and a fresh group will pop up soon.

Any there any other surplus/liquidation stores in the SF Bay Area still around (not the military surplus kind)?

1. In terms of software efficiency, engineers may lament the perceived waste, inefficiency, and imperfection in the produced code, but from a business standpoint it is a rational cost/benefit decision. It is useful to view software through the lens of economics. In economics there is a concept that Labor (e.g. a software engineer) and Capital (e.g. servers, infrastructure) are substitutable. Many sub-optimal programs and systems built with reduced labor cost are perfectly usable by substituting more hardware. Optimization only makes sense where there is a clear benefit that exceeds the cost.

Thus, as a contrived or extreme example, would a manager spend $200k in labor to produce a highly optimized program, hand-crafted in assembly, or spend $500 in labor to produce a program in a higher level language such as Java, that does the same thing but uses more compute resources? The spread in cost between those two choices allows one to throw a lot of hardware at the sub-optimal program. Thus it is frequently a better business decision to produce inefficient software and throw more hardware at it. It may make the engineer feel bad, but what they wish to optimize is not aligned with what the business wishes or needs to optimize.

2. In terms of the short 'shelf-life' of software, the same problem infects hardware, consumer electronics, and other products. I've purchased a number of IPads for my family over the years. After a few years and IOS versions, more and more apps stop being compatible, until it becomes effectively useless even though the hardware is the same as when I bought it.

Again let's view this through the lens of economics. A cynic will look at the IPad situation and and think 'What better way to separate me from my money than to force me to buy a new product every few years, solely by software shenanigans?' Of course businesses enjoy selling more product, but they also have cost constraints in order to be viable (ignoring those who are perhaps making 'obscene profits' before competitors take notice, as my econ professor used to shout so passionately).

We might consider as an alternative that it is simply too expensive to maintain many versions of an app, on multiple platforms, with backwards compatibility and security concerns. The business instead is making a rational decision to only support their application on the OS versions and platforms that the majority of their customers are running at any point in time, similar to how a web developer at some point has to stop bothering to ensure their site works in IE 5.0.

None of that reduces my frustration at planned obsolescence but maybe this is just the reality of things.

3. I'm on the fence about the labor-exploitation part: this seems like a different and very complex issue. Some may argue that more hardware manufacturing provides good jobs without extended education or training requirements, while others may argue that those jobs are exploitative because the working conditions are poorly regulated or the position does not pay enough by their standard.

At a macro level, global poverty levels have significantly decreased over the past 30 years [1], so humanity seems to be doing something right. An optimist may say that as regions of the world move out of poverty, the regulatory environment will inevitably follow to reduce abuse, pollution, and safety risks. Time will tell but it requires patience - human systems are slow to change, in contrast to software and hardware.