The Bumble Berry has a touchscreen, so if you need to use the Raspberry PI OS GUI, you can simple use your finger as a mouse pointer. I've found it works pretty well for the rare occasions that I need to start the GUI.
However, I mostly use this unit in terminal, which means I boot to terminal and only occasionally start up the GUI with startx when I need it.
I use terminal because: I'm trying to brush up on my terminal skills and most of my use-cases are covered in terminal with applications. Some of my favorite terminal applications are:
tmux - for managing multiple terminal windows
nano - for writing code (occasionally I use vim)
tty-clock - nice clock screen saver
lynx - text based web browser. works surprisingly well on some sites like wikipedia
epy - ebook reader - great for reading classic free ebooks from Project Gutenberg
doom - because doom
cmatrix - matrix-style screensaver - looks really cool
My main use case is for learning new code languages - it's nice to have a handheld device on me to practice writing code when I have a few minutes on me but don't have a laptop
The Hackberry looks awesome. I was going to build/buy one, but I wanted a slightly bigger screen and keyboard, and I also wanted to save some money by using an old 3b+ I had laying around. And I wanted to be able to build it quickly from off-the-shelf Amazon components. So all-in I think I spent ~$70 on this one, whereas the hackberry pi would have cost about double that, and then I would have had to buy the CM5 module.
Curious to hear of your experience with the hackberry - I still might consider getting one of those myself.
Yes, the Bumble Berry Pi is a lot cheaper than the Hackberry Pi, but the Hackberry Pi (with a CM5) performs much better.
I don't have a 3D printer, so I bought the kit from Elecrow. I had to buy my own CM5, a 2TB NVMEe SSD, and a suitably sized WiFi antenna (that would fit into the case without modification). I also picked up a $60 portable (1k) HDMI monitor because the 720x720 screen is difficult to use for apps like Firefox and Thunderbird. I use an Apple wireless keyboard and an Acer wireless mouse (both Bluetooth). The keyboard & monitor fit nicely into a plastic A4 document jacket. I was surprised that the Hackberry's USB-A ports provide enough juice to power the monitor. The Hackberry Pi has got a big battery. The one Hackberry Pi design choice that I don't like is the lack of an RJ45 Ethernet port. They could have left off the I2C port and squeezed a PHY in there somehow. (The CM5 has an Ethernet controller.) I've noticed that if I use a USB-A Ethernet dongle, it sometimes hangs under heavy traffic. I've tried dongles with different chipsets and they all seem to have the same issue. The WiFi speeds (as long as you have a good antenna) are great, and are usually faster than a USB Ethernet dongle anyway.
The thing is ideal for travel. It can fit into any hotel room safe, or go with you.
Very cool - amazing that you can fit something that small in your pocket and it can also power a full size monitor & keyboard. It sounds like the Hackberry Pi is a great fit for your use case. I hadn’t considered using the Bumble Berry like that, but now that you mention it, I might try it out like that next time I travel.
It would be nice to have the beefier Pi 5 on Bumble Berry for the rare times that I need a GUI. I mostly use terminal on this device so it’s usually not a problem, but when I do have to use the full GUI I find the 3b+ annoyingly slow.
I briefly tested the Bumble Berry battery with a Pi 500 and although I got an error message saying that the power supply is not capable of supplying 5A, it seemed to run just fine. The battery is rated to 3A, and streaming full screen video on a 4K screen seemed to draw only about 1A (measured by a usb-c pass-thru dongle). However, I did not push the Pi 5 to its limits and I haven’t used it for an extended amount of time so I can’t confidently say how well it would work.
If you’re willing to pay the extra cash and want a smaller form factor it sounds like Hackberry is definitely the way to go.
Curious what bigger screen and keyboard you found. I was looking for similar stuff and struggled to find larger square displays. The closest I could find was spare blackberry passports screens, but you'd have to reverse engineer the screen connector.
Blue Origin | Full Stack Web Software Engineer | ONSITE in Seattle, WA or Huntsville, AL | Full Time | https://www.blueorigin.com
Come build the road the space with us!
You'll be a part of a great team. We have a fun & positive vibe, along with great Principal & Senior Engineers to serve as mentors. This leads to a our team having a solid track record of delivering results for our customers.
Here's what you'll do:
- Build full stack web React web applications with Next.js
- Build data pipelines in Typescript
- Deploy code on Kubernetes with Terraform
- Work directly with customers to gather requirements, build features, get lots of great feedback, and continually iterate to build even better software features
- Work with brilliant rocket engineers
- Create software tools to track manufacturing & cost
- Implement graph data structures & algorithms for manufacturing process directed graphs
- Be a part of a long term mission of millions of people living and working in space
Just applied for the Software Engineer II role, thanks for posting about it! I'm based in Seattle and felt like my skillset really aligned with the job qualifications.
stagnate last 15 years???
Contact elements, bolt preload, modeling individual composite fibers, delamination progressive ply failure, modeling layers of material to a few thousandths of an inch. Design optimization.
ANSYS Workbench = FEA For Dummies.
The list goes on.
Blue Origin | Senior Web Software Engineer | Onsite: Seattle, WA / Los Angeles, CA / Huntsville, AL
My team is hiring a Senior Software Engineer to build software tools to empower our hardware engineers to build better rockets. Our company's vision is to have millions of people living & working in space for the benefit of earth. Our team has really smart people, tackles hard problems, has a track record of delivering results, and is a fun place to be.
We're looking for a full-stack web developer to take ownership over the whole application life cycle, so we're looking experience in the following:
Full-Stack: We recently started using Next.js/Blitz to achieve a more rails-flavored developer experience and we love it. So it's great if you have experience with these also, or at least an eagerness to learn.
Manufacturing: Experience working in a manufacturing environment, and/or implementing Lean, Six-Sigma, & Toyota Production System principles is a plus.
Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to accomplish the same objective with less googling.
As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts.
The best way to work on rails is to either already know rails yourself, or be working with a rails guru, which admittedly there are a bunch of those.
At least with a configuration over convention you can just look at the code and figure out what is happening. With rails, there are certain magical things you just Need To Know and the only way to know those things are to already know them before running into it.
I was going to say the same thing and figured someone else already had.
People would often ask how I knew so much about rails and, ya, the answer is that I read the guides. They are extremely readable and it doesn't take that long. Like a couple of days. You might be surprised how much is retained by just reading through them, even without actually trying things out as you go.
I would like to stress: read the guides, not the docs. Use the docs for reference.
I've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing.
Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem domain.
The rails guides document about 10% of the problem domain. That's mostly ok, because the problem domain exists in the wider world, and there's lots of documentation elsewhere. The problem is that the rails guides document about 1% of the solution space. And that's an issue, because rails claims to be the solution space.
Rails routing is done by passing a block into the framework that's instance_exec'd on... Something. Want to know what, so that you know what API is available to you? Too bad. Here are a list of recipes for the couple most common things you might want to do. Want to do anything more sophisticated, or just understand what your options are? Uh, sorry.
Oh, you want to set and read cookies? Here's a recipe for how to read cookies and how to set them with lots of options. You changed how you're setting cookies and now browsers are returning two cookies of the same name and you want to know how to detect and fix this? Silence from the rails guides! (In fairness, the rack documentation actually included enough information to solve that. But it wasn't mentioned in the rails guides about cookie handling. And the rack documentation was a specification, not a guide. It actually tells you what pieces there are and describes their semantics.)
And it just goes on and on. Rails has about one hundred options for every one actually mentioned in the guides. In some sense that's a good thing. The guides only give you an incredibly limited set of tools. It's very good that the rest exist. But it means that the guides are a very bad way to learn rails, because they don't give you enough information to solve unforeseen problems yourself, or even enough information to understand code someone else wrote to solve those issues.
They put you in the position of hoping someone else anticipated your weird problem and already told you how to solve it. They don't equip you for solving anything weird by yourself.
This feels pretty stawman-y to me. They are meant to be highly digestible examples of everything the framework has to offer. They can be read through quite quickly, yet people still fail to and then you have people who don't know what scopes are or reinvent ways to do enums and what-have-you just because they weren't aware this stuff exists already. If you need to drill down into a specific topic, that's what the docs and blog posts are for. Having the level of detail you describe in the guides would only turn-off newcomers even more.
The guides are great for someone doing what most people use Rails for. Recipes with some side cases are very appropriate for that audience.
If you want to know more about an API, there's https://api.rubyonrails.org and the classes are quite will documented. These docs don't show up in the guides and might be what you're looking for. I should also point out that the API docs are directly linked in the header of the Guides.
> Programming is not regurgitating recipes without understanding.
Call me cynical, but the problem with this argument is that professional software development is about making something that fulfills a set of requirements, and ideally is modular+generalized enough in its design that it can be reused in the future to reduce future development time+costs.
With this in mind, I can see why the Rails documentation wouldn't really care if you learn how Rails works- all they care about is that you know how to use it.
This isn't to say that the desire for greater understanding is bad, just that it's not an effective way to keep an aging, tried-and-true web framework relevant.
You do know you can read the api documentation right? Also you can read the code. The guides are not supposed to have every answer to bugs you encounter. 1% of the solution space? Please, youre so far off it’s laughable
When people ask me how to improve their programming this is my first advice - speed read docs/stdlib top to bottom and keep writing a lot of little things. It’s amazing how many people choose painful path of learning through osmosis.
If you want to make an app from scratch, you must first understand the universe.
This is a ludicrous approach for most. Sure, if you learn from reading and love to read technical manuals, go for it. But to imply this is the best way for most to learn is completely ridiculous.
there are about 35 guides in the rails guide list and half of those are digging deep into the framework... reading the first 10 of them would get you about 95% of what you really need to know in rails so that you can look up stuff later. hell even just doing the getting started guide walks you through a fairly complete rails application.
yah, that's what i did when i first got into rails (~3.0/3.1): read 5-10 of the guides while working through michael hartl's tutorial and reading/watching a number of railscasts (which are dated now, but still have good basic info).
i'm working (slowly) on a personal project in rails 7 using all the hotwire with importmaps newness, and so far, it's been so much better than recent rails' diversion into all that node/yarn/webpacker mess.
I just put all the essential ones through firefox reader mode and the high end of reading them at what is what an average reader can read at based on the word count and it puts it at 10.31 hours of reading. that's a basically complete understanding of rails that most people don't have. to get 80% there you could probably skim most of them and read the main articles on models, views, and controllers and be done in a few hours. (firefox uses a somewhat naive approach though that just counts words and can't distinguish new code vs. the interesting bits so i'd wager the time is less since there is a lot of repetition in code)
it's not a ton of investment compared to how much time it would save you if you use rails later.
"Best way to learn" seems too vague to have a productive conversation about. If your goal is to become proficient with a framework, then reading the docs top to bottom is probably a great thing to do, but if you merely want to hack together a one-off project over a weekend then it's probably not worth investing the time to exhaustively learn about all the features and paradigms of that framework.
Did you learn English by reading the dictionary top to bottom? I’m gonna go ahead and guess that no, you didn’t. You learned English by being surrounded in it and practicing.
You're being strangely combative in this thread, as though you are personally offended by something. What's your problem, and why are you letting it drive you to make such weak arguments? Do you have some past trauma related to being forced to read, or is it just bad experiences with Rails specifically?
It really doesn't take more than a few seconds to figure out why your analogy of learning a language by reading a dictionary written in that language is both stupid and inapplicable here, so I'm not going to try to further address that aspect of your comment (especially since you don't seem inclined to directly respond to anything in my comment).
You’re right, I apologize. You are right that my analogy is stupid on a bunch of different levels.
I’ve been surrounded by so many rails fans who use it for every possible problem. “If all you have is a hammer, everything is a nail” was the epitome of what was happening. Then being left with trying to sift through old versions of documentation, trying to figure out what is the “current” way of doing things in rails vs the previous ways, aye yi yi. Rails has definitely left me with a sour taste in my mouth.
I’m not saying rails is bad, it is great in so many situations. I’m just saying it is not a silver bullet, and the cult behind it has some real blinders on.
I stand by my original argument though that for most people, reading documentation top to bottom isn’t the best way to learn. If it works for you, great.
It's the single most irritating interaction I have had with a coworker, and I have had it at least once at every job I've ever had.
"Hey, thing xyz is super confusing, can you (help me use it|explain how it works|rewrite it so I understand it)?"
"Did you read the document I sent? The document (has sample code that does the thing you're trying to do|explains how it works|explains why the simpler approach doesn't actually work in practice)"
"...No."
It's incredible how some devs can learn 15-20 different programming languages, and completely forget English in the process.
Call me crazy, I’d just rather read the relevant section of code I am working on and be able to understand it from there, rather than first having to understand the entire universe.
When working with a framework, it helps to understand the framework. Then, all the individual pieces make better sense. The advantage is that you only have to gain this understanding once.
A framework is a social contract, if you will. The framework authors are taking on the onus of some complexity to give you a cleaner and easier to grok codebase. The tradeoff is that you do need to read the guides or you will be diving deep into framework internals whenever you want to understand some app level code.
The problem with RoR is that it's an all-encompassing framework. It gives you a huge collection of things you typically don't need — entire major layers like the database are frequently completely irrelevant to projects. This isn't just true of small projects, but can often extend to a large part of a career.
One of the grave dangers that older/wiser programmers have learned is to stop trying to pathologically "drink the entire river". Programming has a constant deluge of new frameworks, tools, and publications coming out, and it's easy to fall into the trap of thinking you need to know, well, everything. I know a lot of 'aspiring programmers' who accomplish next to nothing precisely because they waste most of their time reading about programming instead of actually practicing it. It's sadly rather similar to 'aspiring writers', or any other craft — some reading is helpful, but not when it crowds out the actual task it's meant to teach. Life is short, and you have a choice between "actually making things" and "doing prep work for making things". That's all reading the docs is — it's just prep work. It's completely useless unless it parlays into actually accomplishing things.
There are semi-rare cases where some language/framework is actually teaching you new fundamentals and is worth deep-reading to gain core skills as a programmer. Haskell broke new ground. Lisp was enlightening. Smalltalk was a worthy historical study. Rust is genuinely changing things. Unfortunately, Rails just isn't special.
When I was considerably younger, I used to pathologically do this — I used to buy books on programming, and read them like a school textbook "exam cram". I read entire books on languages (like Perl) that ended up exiting the zeitgeist before I ever did any work in them — and I now have no reason to do so (I feel sorry for Perl, because Larry Wall seems like a cool guy, but perhaps it's a testament to its influence on other languages that it no longer has uniquely redeeming features). I even read books on various applications. Naively, at the time, I looked at learning as a pure, unalloyed good — rather than a dangerous spend of lifetime I'll never get back.
I deeply regret wasting that time on that instead of learning a meaningful skill.
> The problem with RoR is that it's an all-encompassing framework. It gives you a huge collection of things you typically don't need — entire major layers like the database are frequently completely irrelevant to projects.
You do know you can just turn off the parts you don’t want, don’t you?
Don’t want database support? Just turn it off or don’t include it in the first place.
Rails doesn’t have to be “special” it just has to get the job done and it does.
Agreed but as evident in this post's discussion, developers only have the desire to do so once for <insert-favorite-web-framework> and then the need to do so again for any other framework is understood as the other being clearly terrible and immature.
This is a fine answer if you're responsible for a small numbers of technologies, otherwise there are far too many "top to bottom" docs to read in a lifetime, let alone the time you have to meet whatever deadline is in front of you.
Where it gets even trickier, is that these days nobody is responsible for just a small numbers of technologies.
Does your app use the internet? Read about TCP/IP and DNS and other internet technologies top to bottom.
Does your app use a database? Read the DB docs top to bottom.
How about multiple data stores?
Is you app publicly facing? Read about 100 different potential security issues top to bottom.
I could go on...
Only if the docs were good enough! You always have to look at the source code for most Gems and it's full of unnecessary "magic". I guess Django is a much better alternative because of Python different school of thought
I couldn't have had a more opposite experience. My last job was as a solo dev on a legacy Rails 3.2 project. I didn't even know Ruby when I took the job, but have a lot of experience with other MVC frameworks. Learning Rails has mostly been a breeze with a lot of "I wish framework <X> did it this way, this makes a lot more sense" type of moments.
Rails docs are among the best I've ever used for a framework personally. They blow most things in the JS ecosystem out of the water.
Apparently people prefer blog posts to docs. This is not a problem of course, until you need to either debug (hence understand what you're doing at depth) or build something non-trivial.
The problem with Rails is not a lack of blog posts or docs, it's that there's often no way to find what doc you need to read without already understanding the framework. Reading the entire docs and then trying to remember and understand it is a style under which some people learn well and I think it is important for mastery, but the ability to trace back and understand a small piece of a framework is valuable too especially when you're first starting out. Certainly when I try to understand something with node or js libraries I don't jump to blog posts, but I am usually able to find what I need to google to to get the docs I want. That wasn't the case with rails when I was first starting
No the real problem with Rails is autoimport and bad tooling that you can't jump to source easily. I would love rails if jump to definition worked well but it's deal breaker.
I agree that Rails has a kind of a steep learning curve. Also agree that I didn't find the Rails Casts helpful - I found them out of date, so I didn't spend any time watching them.
For me, learning how to learn a new thing at times seems like the hardest part for me. For Rails, the best I've found is the Michael Hartl tutorial [1]. He walks you through setting up a blog with Rails - first the quick way and then the hard way, so you walk away with a nice understanding. He keeps the tutorial up to date and he's been available for questions when I've emailed him. It costs a few bucks ($39) but well worth it IMHO. I spent a few weeks going through that book, did a few apps on my own, and then was able to create new apps fairly quickly.
The official Rails Guides are a great resource too and kept up to date too [2].
Configuring your local rails development environment is pretty easy with the thoughtbot laptop script [3], otherwise it can be kind of a pain to do it from scratch.
I'm appalled everything I realize most developers don't actually read docs... It's unbelievable. Do we expect things to work the way each of us imagine? Or what do one expect when starts using something without reading the documentation?
I have the exact opposite experience. I have done a lot of Java - Spring, Node + Angular / React development. And having just started a job with Ruby on Rails, I have never found a new language + framework + ecosystem to be so easy to jump in on and learn and understand. The convention over configuration works really really well.
If that's not bad enough you're probably working on a legacy app with a whole bunch of mix-ins, proxies, Active Record callbacks, and other nonsense that makes it nigh on impossible to understand what any code does.
Saying that mixins and callbacks are always incomprehensible is silly. They're just a way to pack up code and they can work beautifully. If you don't wanna use them you're gonna have to write the logic in some alternative way, so a bunch of service objects I guess? Does that automatically make code comprehensible - the fact it's using many small classes? I'm sure people can and are writing shitty services as well.
There’s nothing more frustrating than debugging some ruby module with 10 different mixins defining functions with generic ungreppable names like “user”. Then it turns out the mixins have mixins.
The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails
Rubymine's autocomplete got to a state where I barely ever have to grep anything.
Look what you're describing can happen, it's just not that often or is the norm. It's usually some crappy legacy project no one wants to upgrade or touch that reaches such a state, there's absolutely no reason why what you described can't be refactored. The fact it isn't being refactored tells you more about the company/teams working on it than about the framework.
> The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails
This can be said the same of any other framework or language. It is up to your team to organize the code, write documentation, agree upon linting rules and of course encourage best practices. If you’re leaving those decisions to each engineer writing code - thats the problem
I’m not sure if this is still a thing but I remember the Rails community being obsessed with aliasing methods and other ways of dynamically defining code at runtime. Coupled with the fact that Ruby is already hard to statically analyze and ‘grep’ is your only hope… good luck following the alias_method_chain rabbit hole…
So maybe your problem is there is too much documentation that spans too far back and getting current relevant examples and docs is the hard part. The rails guides are kept current, but any popular framework that has been around for a while is going to have a similar problem. Rail's guides are pretty good compared to many others I've seen. Also there are books, courses, video series, and plenty of other resources that are up-to-date. There is no shortage of high quality up-to-date learning content available. It just may take some work to weed out some of the older content.
There is a reason why most coding bootcamps are based on Rails and React instead of Go, Java, PHP, .Net etc - they are easy to learn, work and reason with.
> the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts.
I mean, when learning a new language or framework, reading the docs or watching videos and tutorials are part of the course? What other MVC frameworks have you worked with where someone new could just go in and start building an app without actually learning it first?
I don't think the Rails Guides mention Devise, the authentication gem, which is pretty important if you want create a public facing website with users. The devise documentation is pretty good though. Again, a little bit of a learning curve, but once you learn it you can add user authentication to your site pretty quickly.
You don't need devise, so I think it's good it's not included. It used to be that devise was good to use as it had the best practice way to set up the password fields etc. But that has been moved to rails core. It's still worth reading the devise documentation, but I'm so familiar with how it sets things up I can just set it up manually faster than messing around with devise itself.
AFAIK there's nothing in the rails guides to help with authorisation. I googled and couldn't decide between pundit and cancancan. I went with the latter because of some tutorial videos I found. But it wasn't easy: 1. I couldn't find documentation for methods so common as `can?` [1], and 2. the 'magic' of how rails automatically sets instance variables differently and sometimes not at all before each action was also very confusing. Like many other things, it was confusing until you understood what it was doing, but figuring out exactly what it was doing and why took hours of experimenting with the behaviours of each action, and being the recipient of quite a lot of condescension on stack overflow for even asking.
When I learned rails the community had a fundraiser to fund the documentation writing (this was v0.7 or so IIRC). Being able to read the docs sounds like a dream come true.
As a beginner, I didn't find this to be true. Django worked fine and could do what I wanted.
I suspect that if I were coming from Javascript where "I know what I want to do" if only I could "make Django do it", I would feel the impedance mismatch.
This is a very standard problem--"You can write FORTRAN in any language." Leaving behind the idioms you are used to and adopting the idioms of your new environment takes time and energy.
There was a lady in one of my previous projects whose job was to maintain the integrity of sensitive financial data (she was doing a lot by hand, as they wanted a human to check every number). In the 2 years or so I worked there, there was not a single mistake from her. I didn't hear much appreciation for her from others, but my CTO used to call her the most important person in the company.
Some tools, some people just work, just do their job quietly and efficiently. They do not get any appreciation, precisely because they are too efficient and go unnoticed. JS is not one of them for sure.
I doubt this, at least for my country a simple search in LinkedIn of "NodeJS" and "React" have tenfold the results of searching for "Rails" or even "Django".
It might be a bubble but basically every new startup and small/midsize company are using NodeJS and even big companies are building new services with it.
At the least, it is a self-reinforcing tragedy. ("Look, all the big players use framework xyz as well, it cannot be that bad then!") JavaScript being thrown at problems, for which it is not so well suited with all its warts. Web developers being thrown at problems, with which they do not have experience, because "Now we can use JS in the backend as well!". In many cases it sets organizations up for getting stuck at local maxima or for straight failure.
Never thought from this angle and it does make sense. Probably doesn't explain all the difference, but a considerable part of it is not unreasonable to assume.
You might need to design a new back panel for the enclosure.