softwaredoug

Solr needs opinions, because Solr documentation gives you way too many options. It's hard to navigate the best practices for using Solr. Some of my opinions based on dozens of Solr projects :)

Prefer preloading static, classic config files over managed schema, config API, or schemaless

Schema files are a good thing. They are declarative, and not letting them change at runtime prevents all kinds of security issues. Further, classic schema / solrconfig support all of Solr's functionality and are well documented with tons of examples online in blog articles and stackoverflow. Using managed schema or the config API takes a lot of experimentation.

Static configurations can also be easily version controlled. As I've learned as a long time Elasticsearch user, this is one of Solr's advantages. Having an API for changing every underlying config option of your index means finding the code that made the change is rather time consuming.

Static configuration is also good separation of concerns. You cleanly separate

usametov

//here is document with NESTED Array
{
    "_id": "xyz-800",
    "site": "xyz",
    "user": 800,
    "timepoints": [
        {"timepoint": 0, "a": 1500, "b": 700},
        {"timepoint": 2, "a": 1000, "b": 200},
        {"timepoint": 4, "a": 3500, "b": 1500}
    ]

johnduarte

FYI, for those of us running Debian based systems rather than RedHat, the BlueJeans RPM can be successfully installed via alien

Steps to install BlueJeans on Debian

• Download BlueJeans RPM
• Install alien package sudo apt-get install alien
• Convert BlueJeans RPM to a DEB package sudo alien --to-deb --scripts bluejeans-*.rpm
• Install resulting DEB sudo dpkg -i bluejeans_*.deb
• Run BlueJeans with /opt/bluejeans/bluejeans-bin

You may get an error loading the expected udev library

bobbygrace

Hello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets

---

Trello CSS Guide

“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”

You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?