That's really interesting. Hmm... it's too bad that there's no easy way to try out the keyboard and its unique switches before committing. But it's intriguing nonetheless.
Can you share how long you're looking to run the preorder/early bird special?
400 karma · joined January 4, 2011
Can you share how long you're looking to run the preorder/early bird special?
I'm curious about the switches you're using. On the tech specs it says: "Dual steel arm scissor switch w/ retention spring, 40gf actuation force"
Are they custom switches then? If so, are they most similar to current Magic Keyboard switch feel, or something Choc or MX low profile, or their own thing altogether?
- calibre-web, as a pure web front end to the calibre db
- Calibre Web Automated, which is a rewrite of the app, with a better web UI, that is faster and adds functionality
- Grimmory, a Java-based book mgmt. app w/ a web front end too
- BookOrbit, similar to Grimmory but written in Node and seems to scale better w/ 100k+ book libraries
The better way to get books onto KOReader is via connecting to these apps' OPDS feeds. Wireless, and most of these other apps have better library organization.
I'm a director of eng. as well, so there'll be times when I reconnect with former managers and reports and provide/get mentorship that way as well. The key is to actually keep in contact and in touch beyond any singular job; if you were able to mentor them while you shared an office, that relationship is still valuable afterwards. Of course, this means that you have to develop the skill & reputation to be a good mentor to others around your job.
I've been a software eng. manager for a couple of years now, currently a director of engineering at a mid-sized fintech company. I've always mentored other managers within the companies I worked in, but I'm realizing there's plenty folks who move into mgmt. for the first time w/o much support, and even a chat or two goes a long ways to making the role transition less daunting.
I'll say that after a year's worth of experience with Ember, we've gotten much better at it, but we've still had to add our own components (e.g., a validation framework) or fork off what components and use + fix them before they're completely production ready. We accepted these tasks as a cost of living on the bleeding edge, but admittedly given the rapid pace that the API has changed in the past year, we've acculumated a bit of necessary tech debt.
W.r.t. Ember Data, that wasn't a consideration for us, as the component didn't exist when we were building Dashboard. That said, we chose to integrate with ED in one of our more recent features, and while I'd be lying if I said there weren't any pain, what we took away were learnings about how our non-ED models related to each other and informed subsequent refactors that made the overall app better.
But to your first point, I don't think it's just learning HTML and CSS syntax. For example, I've never seen a SE break out XScope and measure the exact pixels between two elements, obsess about the opacity of a drop shadow, or spend a few hours to tweak the bezier curve of an animation. It's like saying that SEs will just struggle with design initially.
For example, I was working on a multi-step activation system where I had to get the user in a certain state no a specific UI element showed up. That required spending 5-10 min. every time to set up that user, which would go away once you use that button, and development would have taken days.
That is, until someone showed me what the Activation schema + model looked like and how to just toggle the boolean or attach an expected relation. You could maybe argue that there should be an admin interface for manipulating model state, but nobody else really would need it: BE devs can already change the models, and business types don't care about this particular state of the user.
I think a part of it is ego, especially nowadays - some really good engineers are doing their own startups now, and when these companies start hiring they're looking for people just as good as they are, which means taking a page out of the Google/Facebook style interview process. I've met and worked with people who, while with great intentions, think great software engineering comes from graduate-level CS studies.
That said, resumes and achievements aren't great indicators of success because so many people have good-looking job histories and many can also sound good just talking about their experience. For me, front-end web eng. has become a pain to hire for; too many candidates put down things they don't know enough about, and unless they have fully-viewable source online it's hard to tell whether they accomplished much of anything in their past projects.
I do think our current standard of heavy whiteboard interviews is misleading, though, which is why I prefer pairing interviews when given a choice. Working with an engineer is a great way to measure cultural fit.
And finally, companies are super careful with filling a position because while firing someone is at-will, the cost in bringing that person up-to-speed, dealing with the bad player's code and work, the messiness in letting that person go (in planning, morale, etc.), not to mention salary and severance make everybody err on the side of caution.
And it so happens that Closure code tends to create a ton of extra DOM structure within the JS code, so the 50-level-deep <div> tree isn't much of a surprise, especially with something as complex as the Gmail UI.
Being passionate isn't a substitute for mastery, getting burned out by hard work, and general marketability of an idea or product. No matter now passionate you might be about widget-building, your lack of skill and the lack of a market for widgets is the cold hard reality.
For dev work, I'd say the nicest thing about the 27"s is the ability to put two full pages side-by-side, either a browser window + IDE, or vert. split IDE code panes. 1920px isn't quite there for two panes of code.
And personally, I've had 2+ 24"s, and I've actually found it too cumbersome: having emails/IM's on a second window actually becomes distracting, and moving your mouse cursor across so many pixels was less precise than either alt-tabbing to the right program or switching spaces/virtual desktops w/ a keyboard shortcut. For me anyway, 27" is the sweet spot.
I've seen more companies look for other publicly visible areas of code output: - Github/Stack Overflow/Quora - Blogs/social sites like HN, reddit at times - Open source projects
Internships or experience at well-regarded companies also helps a lot, and once you get through one of these avenues it's easier to keep the ball rolling and get introductions to the hot companies in our industry.
Of course, you still have to pass the interview, regardless of which university you studied in. =)
There are devs struggling to make a few hundred sales in the iOS/Android app stores while producing quality products. Selling software isn't easy, and making it sound trivial well...makes it sound like a scam.
A FE Eng. is still a software engineer, which means you ought to be able to pick up any backend language, be it Python, Rails, PHP, or a Java/C++ service. A lot of the time you'd be tasked with bugs/features that require a lot of FE work, and some backend work as well; it's so much more efficient for you to just write the backend handlers, esp. when it's usually a stone's throw away from an ORM layer or a simple SQL call.
I'd also consider knowing something about UI/UX to be a nice bonus. In reality, your UI designer isn't going to provide mocks for every page and every interaction; you're going to have to fill in the gaps, and probably do so without a huge dropoff in quality. At the same time, I usually find myself bringing another perspective from the UI side when talking w/ the designer, and since most places only have one UI guy it's valuable for them to get feedback, even if it's from someone not at the same level.