Archive

Technical

Using Svelte with CherryPy

July 25, 2023
Article, Technical
Leave a comment

Using Svelte with CherryPy

I’ve been using CherryPyfor decades. And along comes Svelte…

Using Svelte with CherryPy is like combining any frontend framework with a backend framework. In this setup, Svelte is responsible for building the client-side user interface, while CherryPy is used for server-side processing, handling HTTP requests, and communicating with databases. Here’s a simple guide on how you might use these two together:

  1. Separate Frontend and Backend Development: Generally, it’s a good idea to keep your frontend (Svelte) and backend (CherryPy) code separate. This makes it easier to manage both parts of your project.
  2. API Design: Design your server-side endpoints in CherryPy. These endpoints should correspond to the different types of data your client might request. For example, if you have a blog, you might have endpoints to get all posts, get a single post, create a post, update a post, and delete a post. This is often done using REST or GraphQL.
  3. Server-Side Logic: Implement the server-side logic in CherryPy. This involves processing requests, handling business logic, and communicating with databases.
  4. Fetch API in Svelte: In your Svelte application, you can use the Fetch API to make HTTP requests to your CherryPy backend. This can be done directly in your Svelte components. Svelte’s reactivity features make it easy to update the UI when data changes.
  5. Websockets: If your application needs real-time updates, you could use websockets. Both Svelte and CherryPy have support for this.
  6. Build & Deployment: When you’re ready to deploy your app, you’ll need to compile your Svelte app to JavaScript, HTML, and CSS. These static files can then be served by CherryPy or any static file server. On the server side, you’ll need to deploy your CherryPy app to a server that supports Python.

Remember, both Svelte and CherryPy are flexible and can support a variety of architectures, so you may need to adjust this setup based on the needs of your project. Additionally, when developing applications, it’s important to consider factors like error handling, data validation, security, and performance optimization.

Why is True Fellowship So Rare, Especially in Tech?

May 3, 2023
Alien tech, Article, Collaboration, Culture change, Fellowship, Organisational effectiveness, Software development, Teambuilding, Technical
Leave a comment

Why is True Fellowship So Rare, Especially in Tech?

Why is fellowship in organisations, particularly in tech companies, such a rare phenomenon, and yet when it does emerge, it’s immensely powerful? What are the factors that make it so elusive, and conversely, the elements that make it thrive when it does manifest?

In the world of technology, competition and individualism often take centre stage, overshadowing the potential benefits of collaboration and fellowship. Could it be that the pressure to innovate, coupled with the race to stay ahead of the curve, pushes people to focus more on their individual achievements and personal wellbeing rather than the collective good?

There’s also the issue of diverse backgrounds and skill sets. With experts in various fields such as engineering, design, marketing, and more, it’s possible that this diversity might inadvertently create silos. Do these specialised domains lead to a lack of understanding and empathy among team members, preventing the formation of a cohesive, supportive environment?

And yet, when fellowship does take root within tech organisations, its power is undeniable. Why is that? Could it be that the amalgamation of diverse perspectives, skills, and experiences in a collaborative environment leads to breakthroughs and innovations that might otherwise be impossible? When individuals work together, for example with Ensemble Working, sharing their knowledge and challenging one another’s ideas, they pave the way for novel solutions and approaches.

Perhaps another reason for the potency of fellowship in tech companies is the sheer complexity of the problems they tackle. The adage “two heads are better than one” rings true, as the collective intelligence of a group working in harmony often surpasses that of even the brightest individual. In an environment where fellowship thrives, team members can rely on each other’s strengths, ultimately yielding better results.

So, why is fellowship so rare in tech organisations? It appears that the competitive nature of the industry, coupled with the diversity of skills and backgrounds, might pose challenges to fostering a collaborative environment. However, when such an environment does emerge, it unlocks the potential for innovation, breakthroughs, and success that are unparalleled in their impact. Thus organisations maigh choose to recognise and nurture the power of #fellowship to stay ahead in an ever-evolving commercial landscape.

Tech Solutions vs. Cultural Issues: Can Tech Fix Culture?

January 24, 2023
Article, Culture change, Technical
Leave a comment

Tech Solutions vs. Cultural Issues: Can Tech Fix Culture?

Cultural issues refer to the social and behavioral norms, assumptions, and beliefs that shape a society or group of people. These issues can range from discrimination and prejudice to cultural appropriation and misunderstanding. Technical solutions, on the other hand, refer to the use of technology and data-driven approaches to solve problems and improve efficiency.

The question of whether we can fix cultural issues with technical solutions is a complex one. On one hand, technology and data-driven approaches can be incredibly powerful tools for identifying and addressing cultural issues. For example, data analysis can be used to identify patterns of discrimination and bias in the workplace, while social media and other digital platforms can be used to promote awareness and education about cultural issues. Additionally, virtual reality and other immersive technologies can be used to simulate experiences and foster empathy, which can be a powerful tool for addressing cultural issues.

On the other hand, it is important to recognise that cultural issues are deeply rooted in societal norms, assumptions, and beliefs. They are often the result of centuries of history and are deeply ingrained in our social and cultural fabric. Therefore, simply implementing a technical solution is generally insufficient to address these issues. Instead, a more holistic approach is needed that addresses the underlying social and cultural factors that contribute to cultural issues.

Furthermore, it is essential to note that technology can be both a tool and a hindrance in addressing cultural issues. While technology can be used to promote awareness and education, it can also be used to perpetuate stereotypes and discrimination. For example, algorithms used in social media and search engines can perpetuate biases and perpetuate harmful stereotypes. Therefore, it is essential to be aware of the potential downsides of using technology to address cultural issues and take steps to mitigate these risks.

In conclusion, while technology and data-driven approaches can be powerful tools for addressing cultural issues, it is important to recognise that these issues are deeply rooted in societal norms, assumptions, and beliefs. Therefore, a more holistic approach is needed that addresses the underlying social and cultural factors that contribute to these issues. Additionally, care should be taken to ensure that technology is not used to perpetuate stereotypes and discrimination. Ultimately, addressing cultural issues requires a multifaceted approach that leverages both technical solutions and social and cultural understanding.

Quickie: Love Of Coding

June 18, 2022
Alien tech, Coding, Culture change, Lamentation, NoSoftware, Organisational effectiveness, Quickies, Quintessence, Technical
1 Comment

After all these years, I still love coding (as in writing software).

It’s just that it’s tainted by the certainty that there’s so many other more effective ways of adding value and meeting folks’ needs.

Spending time coding feels so… self-indulgent.

Microservices In Embedded Systems

April 25, 2015
Technical
5 Comments

Microservices In Embedded Systems

I don’t write many “technical” posts, finding people and organisations more challenging, and hence more interesting, but this is one. If you like the diversion, let me know and I’d be happy to write some more such posts.

Some years back I was running a boutique embedded systems development company, in partnership with a hardware engineer. He’d design and build the hardware – micro-controller based – and I’d implement the core functionality in software. Mostly in C, C++ or Python, with some e.g. PIC assembler here and there. OSes were Linux, WindowsCE, or naked. Approach was entirely Agile (on both the hardware and software fronts).

We specialised in hyperconnected devices – now more widely known as the Internet of Things – so every device we designed centred around an embedded web (HTTP) server.

One particular project – at the higher end of micro-controller capabilities, with virtual memory addressing and a fairly beefy CPU – was an event logging device with e.g. remote access (dial-in or ethernet) capabilities, a touch panel for local admin, and a bunch of digital I/O lines for scanning the connected devices to be logged.

I chose Python as the prime option for the implementation, with Javascript and CSS for the touch UI, some C for low-level hardware (device driver) functions, and Json for initial device configuration a.k.a. policies.

Once I had a Python implementation that would run on the platform, I gave some thought, as I was writing some early code, to a suitable architecture. I knew the client had a vague interest in extending the range of product variants in the future, as well as possibly adding more features, so although not a priority, extensibility was at the back of my mind.

Aside: Another reason for Python being the favoured implementation language was the excellent CherryPy webserver package, which I had used often before. Unfortunately, it turned out that CherryPy wouldn’t run on the platform (WindowsCE), and tight schedules did not permit an investigation as to why. So I went with a basic SimpleHTTPServer implementation instead.

More pressing, in terms of getting the whole thing working, was the memory usage of each Python process. And the relative shortage of memory on the device (suggested by the economics of the design). This consideration was paramount, it turned out, and a good deal of the work was a consequence of shoe-horning the necessary functionality into the memory space of the device.

Eventually, the architecture evolved into circa a dozen separate, cooperating Python processes. (Note: I stuck with Python, because actually implementing the necessary functionality in Python was much quicker and less painful than doing the same in e.g. C or assembler).

In retrospect, today we might choose to call this a microservice architecture. Each Python process ran independently of the others, doing its small bit, and interacting with one or more of the other services as and when necessary.

The microservices included:

  • Watchdog
  • MCP
  • Networking
  • TimeWarden
  • MediaWarden
  • EventScanning
  • EventLogging
  • Webserver
  • RemoteCommandListener
  • SyncSource
  • DeviceStatus

Aside: Actually, there were rather more microservices than this originally, but I had to combine some in order to meet the memory constraints.

At the end of the project, it was clear (to me, not to anyone else) that, serendipitously, the architecture was such that adding new features, even whole new microservices, would be a piece of cake. I’m not aware that this was ever appreciated, let alone acted upon (no one else involved was at all software savvy).

Have you worked in embedded systems development? Have you ever seen or considered the pros (and cons) of a microservices-style architectural approach?

– Bob

Further Reading

Stop Thinking About User Interface ~ Juan José Ramírez
Windows CE: Synchronization Objects – Events ~ Bruce Eitman