4 ms·
Pretty much everyone is in the same boat. Even if you have an advanced degree, most of what businesses need is plugging together components and adding business
by ghc 8y ago
Pretty much everyone is in the same boat. Even if you have an advanced degree, most of what businesses need is plugging together components and adding business rules to create a product.
As a discipline, we're too young and our technology is too immature to support a true split between engineering/science and computer programming.
If you want to work on interesting problems you're passionate about, there's a few ways to do it.
First, you can do research. Years ago I joined a lab as a professional researcher to follow my passion for machine learning and sensor networks. It's not the easiest path, but labs need disciplined programmers to complement the skills of PhD students.
Second, you can consult. If you're passionate enough about a topic that you have encyclopedic knowledge, I guarantee there's someone out there who will need that expertise and will pay for it. It might not cover all your bills, but it gets you exposure (and potentially a job if they need your skills a lot).
Third, you can start a company. I followed my passion for the challenges of learning from sensor data at scale into entrepreneurship and eventually started a company, http://sentenai.com http://sentenai.com . As a technical founder, I chose carefully the technologies we use (Haskell) and the problem we were tackling (making it fast and natural to combine multiple sources of time series data and find temporal patterns). You still need to solve somebody's problem and build a business, but you can at least lay the foundation.
- flowless 8y agoNice, I'm building something similar with TTN - using Haskell to glue MQTT/SQL/WebSockets to be able to stream data from sensors and also optionally store data in timescaledb. For web fronted I really want to try miso (https://haskell-miso.org/ https://haskell-miso.org/).
- ghc 8y agoUnless you're targeting consumer you might want to be careful with tech like web-sockets. After a decade of using sensors in industrial facilities I've come to appreciate the value of on-device buffers and transactional logging systems that don't maintain persistent connections. Real-world environments are unfortunately really tough on technologies designed for browsers.
- flowless 8y agoI'm totally in the you-dont-really-need-web for everything group but yes, this can be considered targeting consumers as-in ordinary people who want to use localized version of TTN. I don't really approve use-cases like running a webserver to control lights on ESP8266 where simple TCP sockets would do. Btw I've written an implementation of ZRE protocol which you might possibly find interesting - https://github.com/vpsfreecz/haskell-zre https://github.com/vpsfreecz/haskell-zre
- ghc 8y agoHaskell-zre is pretty cool! I think I'll have some fun playing with it with some of our demo IoT setups. We're purely in the backend data infrastructure business so I don't do deployments any longer, but we'll probably have some fun with it anyway :)
- kdv 8y agoYou sound like you have some experience in this area so I'll ask. I'm working with fielded devices that typically sit on enterprise networks. We operate much like an IoT device, but without the hardware constraints. The current c2 system uses a traditional polling REST HTTP protocol and we're looking to migrate something more real-time (for config pushes) and lighter on the server. Currently looking at everything from HTTP/2 SSE, Websockets, MQTT over WS, or even HTTP using something like Google's Cloud IoT. As you can probably tell we'd like to keep the wire protocol enterprise-network friendly. Any advice?
- ghc 8y agoIt really depends on your edge data model, but the enterprise network should always be considered hostile. At my previous company we ran SSH servers on our gateways for server->client pushes and it ran into the fewest problems with enterprise firewalls. We also ran our own mesh wireless networks a lot using our own gear. I'm guessing that's probably not an option, but when there's no admin running around looking for unauthorized wireless signals it's quite efficient. Now all of these require a local host machine (or several) behind the firewall that do the brunt of routing and orchestration for pushes. There's a good reason for it though: It's a lot easier to get several hardened systems authorized to cross the firewall than a bunch of IoT devices. And if you can't get that authorization, you can put a cellular connection in the box or boxes more cheaply than one in every deployed device. Happy to chat more if you want specific advice about certain situations. I also spend a lot of time investing in and mentoring Boston-based IoT startups so I have seen a broad cross-section of situations that can happen. brendan@sentenai.com
- sridca 8y agoMiso is great. Also checkout reflex; and the recently open-sourced https://github.com/obsidiansystems/obelisk https://github.com/obsidiansystems/obelisk