-
This is super cool, I really appreciate all the strides the Postgres team have made the past couple of years. Very impressed!
-
Hultner
6 months ago
|
link
| on:
My Python Development Environment, 2018 Edition « Jacob Kaplan-Moss
I’ve migrated to use pipenv in my daily use for development (used pip with virtualenv before).
However pipsi have cause much more headaches then it has fixed for my part, it never quite worked as it should and the installation was both cumbersome and bug riddled. Once I had it semi-installed it was almost impossible to get rid of and my system Python is a bit broken ever since.
-
Hultner
6 months ago
|
link
| on:
What is Debian all about, really? Or: friction, packaging complex applications
I myself has noticed that Debian packaging is really hard to get right as a newcomer.
It’d be great if their was both simpler tooling a more concise guides on getting started. A PDF with 50+ pages/slides of information isn’t a good quick start format.
-
A coworker once spent a couple of months trying to get a package upsteamed to Debian. By far the hardest part was waiting for the upstream maintainers to comment on the package. It took weeks to get any kind of feedback at all. By that time my teammate had completely forgotten all the packaging details but fixed the comments anyway. After not hearing back about the fixes for another couple weeks he just gave up. Someone else ended up finishing the packaging.
-
A few of these are mentioned in the article under the “Things for Debian to improve” section. I think improvements here could help reduce friction at the margins, but not sure they address the more fundamental disconnect. For example tooling/docs improvements would make it easier for the subset of upstream developers who value a Debian-style packaging system but currently don’t bother with it due to annoyances on that front, which is definitely not nothing. But it wouldn’t fix the problem with regard to upstream developers whose release cycle just doesn’t fit the Debian packaging model at all.
-
-
-
I’m building this kind of greenhouse automation system to monitor my plants at home and maintain appropriate conditions throughout the winter (by turning on/off some of the electric heaters, ventilation, light, sending email alerts when things get too much out of range). It’s all PHP, which is not sexy - but it works - and a few python or bash scripts running on the Raspberry Pi machines that are scattered in the rooms.
My goal is to eventually use machine learning to give advice on when to water the plants (and eventually do it automatically). For now, I manually record the watering times until I have enough data to use. For now, it seems like dirt colour (the system also takes regular pictures of the plants) is a rather good indicator, but not good enough.
The clean, server-side parts of the code are here.
-
Awesome project! I’ve done this at an industrial scale for multi million dollar greenhouses at my previous job. I initiated and developed with our team a system then called Cortex now called HelioCORE ( http://info.heliospectra.com/heliocore ). It was a modular system which had an easily extendable frontend and backend, all our own features were built a independent modules in the same way so the extensions would be first class citizens. We built it in Python3 with a react frontend but you could pretty much build the modules in anything that speaks http, the core module would broker the connection to hardware using multicasting, udp, broadcasting, plc, modbus, etc through a simple http/websocket JSON-API. We also used some quite sophisticated algorithms which learned to recognize i.e. at what times the sun would pass by beams in the structure etc.
Was great fun and very exciting to work with something so tangible.
-
Thanks! My system is flexible enough that I was able to add (in the private part of it) things like my weight (from a connected scale) the times I leave/come back from work, presence of my bike in front of the house, or getting intrusion alerts, stuff like that, not very useful but interesting to do.
For the important data though, temperature/light/humidity mostly, I’m struggling to find adequate sensors, good parts of my space are far from electric outlets so I tried to go with battery-powered BLE sensors, but most of those I tried aren’t as precise, long-lived and easy to configure as I’d like. But I guess real professional greenhouses are already wired so this wouldn’t be an issue for you?
-
-
-
-
Hosted a Hackathon at our office (a “small” castle) weekend, which was great fun and now I’m evaluating the success and also onboarding a new hire for backend+devops. Will write a article for our company blog about the event with some highlights this week.
Other then that I’m looking for a good platform for a smaller firm to deploy Python services on our servers, leaning towards Kubernetes, hoping it’s not to big for a ≈15 person startup. We also have to figure out how to handle file storage if we go the container route.
If anyone got experience in it I’d gladly appreciate some tips and pointers.
-
Raspchat
I am working on refactoring frontend of http://raspchat.com/ previously it was written in Vue 1 without using any kind of packaging tools (webpack or rollup). I am refactoring frontend to be more simple with a new idea around chatting in multiple rooms, this time with hyperapp, and rollup. Staying away from react :) trying to keep it minimal. Few weeks back I switched backend from Golang to Node.js (for simplicity in codebase). I hope pretty soon I will finish the pending tasks and hit v1.0.
-
-
Download link will be linked to Github. About IRC I have similar ideas, but every time I think about it, it begs the question if I should just use an IRC server with Node.js doing the WebSocket relaying; which leads me down the path of https://github.com/kiwiirc/webircgateway/ . I think I will keep it simple for now and gradually evolve it into something bigger.
-
-
-
I’m not sure why fewer than 200 people said they use Haskell at work in the previous question but more than 600 said they use Haskell at work at least some of the time in this question.
Was the question “Where do you use Haskell?” multiple choice, or was the survey using radio buttons? Could be the source of the discrepancy.
-
The “where do you use Haskell” question was multiple choice (check boxes). The “do you use Haskell at work” question was single choice (radio buttons).
-
I had this same problem with State of Elm. The first go ‘round people told me that the binary yes-or-no was unclear because they felt they had to be using it in production. But that wasn’t my intent, so this year I tried to fix it by making the “where are you using Elm” question have the following choices:
- I’m just tinkering
- Don’t feel ready for production
- No code in staging or production but feel capable
- In development towards production
- In production on a side project
- In production at work (internal)
- In production at work (user-facing)
Next year I’m going to break it down even more. It turns out that a lot of things I thought were yes/no initially are actually sliding scales. (Except for “can I have your email” or really really specific and leading questions.)
-
That is actually quite interesting, I’ve been tinkering with both Haskell and Elm at work but haven’t used them on any project meant for production.
I usually experiment with a lot of languages for smaller side projects and when architecting a new product and evaluating tech choices, many of these are never put into production usage while some do.
-
-
-
I’m building a stateless service for generating iOS Wallet passes through a json api to be used at checking. The service will also be able to generate SVG/PNG QR-codes and icalendar events.
My PoC is done and I’m mainly working on making the API thorough enough while staying really simple for the basic use cases. A problem I noticed is that generating a rasterized QR-code in a requested size can be slightly problematic due to the way sizing with versions works, if anyone have first hand experience or recommendations on how to tackle the sizing dilemma without constraining the requester to predefined sizes I’d appreciate pointers. Right now I’m leaning towards finding the largest possible scale with needed version to encode the data that fits within and placing that image centered on a canvas of the requested size, drawback is that there will be unpredictable whitespace surrounding the code.
-
Surprised me as well, however I really like it as a formal standard including subdomains so one can use it reliably. Can see myself having apps listening to
appname.localhostgiving you a meaningful and rememberable name. Of course to my current knowledge this would still need data routing through an app proxy if the same TCP port is used. -
-
Hadn’t heard about DSSSL before but I must say that I love that approach, would have been much nicer then much of the mess we had to go through with CSS the past two decades.
-
Over time I become more and more fond of calver, I can never remember arbitrary version numbers even for my own software.
Roughly remembering the state of the project at a specific point in time is often much easier, and it’s also often easier to backtrack problems & incompatibilities. Very hard to give up SemVer though, especially before 1.0.