I was reading Scott Hanselman‘s blog about running background tasks in ASP.NET and I was surprise to discover Hangfire! My go-to solution for background tasks in ASP.NET is either console app — straightforward to implement but requires a lot of work — or Windows Scheduler — often kludgy and crash-prone. This is such a relief for me (emphasis mine):
The best feature from Hangfire is its built in /hangfire dashboard that shows you all your scheduled, processing, succeeded and failed jobs. It’s really a nice polished addition.
This drastically reduces, if not eliminates, the need to remote the server just to the check whether a background task has crashed or not; my top pet peeve when implementing background task solution. Had I known Hangfire a few months back, it would’ve saved us a few days of work. Nevertheless, I’m sure it will be a mainstay in my .NET kit.
John Gruber speculating the next iPhone screens:
But after giving it much thought, and a lot of tinkering in a spreadsheet, here is what I think Apple is going to do:
- 4.7-inch display: 1334 × 750, 326 PPI @2x
- 5.5-inch display: 2208 × 1242, 461 PPI @3x
@2x means the same “double” retina resolution that we’ve seen on all iOS devices with retina displays to date, where each virtual point in the user interface is represented by two physical pixels on the display in each dimension, horizontally and vertical. @3x means a new “triple” retina resolution, where each user interface point is represented by three display pixels. A single @2x point is a 2 × 2 square of 4 pixels; an @3x point is a 3 × 3 square of 9 pixels.
It’s lengthy but if you geek out on this kind of thing, it’s worth the read.
Growing Android fragmentation — or device diversity if you prefer — has been visualized in a new report by crowdsourced cell phone signal startup OpenSignal, which has surveyed 682,000 devices to build its annual peek at Google’s mobile OS ecosystem.
I don’t know how Android apologists will spin this but if you don’t call this fragmentation, I don’t know what is.
Last week, The Verge had a controversial article about Slack:
Are people using Slack to replace workplace email wholesale?
Yes, for a lot of three-person teams, a lot of 10-persons teams, and a lot of 100-person teams. It’s all or nothing. If half of your team was not on it, then the whole team would stop using it pretty soon.
We’ve been using Slack since February this year (yes, really). Initially, I thought it was just another app in the crowded messaging space. Nonetheless, I was impressed by its UI so I gave it a shot. I asked my team to sign up and try it out. Our usage eventually dwindled because we are using Skype as our primary communication tool. Slack as a communication platform just cannot compete with Skype.
This goes on for a while until I discovered Slack’s true power: third-party integrations. Because of our recently-implemented code review process, I wanted to be notified whenever a developer commits a code. Incidentally, this is right up Slack’s alley. Slack has an impressive roster of third-party integration, including Bitbucket. For every repo that I want to be notified, I simply create a hook and pair it with a Slack channel. Viola! Instant commit reminder. Here’s another cool usage scenario that we recently adapted: we wanted to be notified whenever a file is dropped in a certain OneDrive folder. This is part of our internal backup process. Using a third-party app called Zapier, we were able to bridge Slack with OneDrive, which is pretty sweet.
Overall, Slack didn’t kill email in our office. At least not yet. In spite of that, we’re a happy camper. We are now obsessing on how we can integrate it further with our internal processes.
Then I found moment.js. You’re welcome.
Rappler has a good piece about the whole Jollibee #ChickenSad fiasco. I know a little about what happened but let me say it upfront that I am no in way involved in the project. Some of my friends jokingly asked me if we were the reason why the stores are out of chicken. I would be mortified if we were.
I cannot tell what I know (I’m under NDA) but I agree to most of the points that the author made (I distinctly remember suggesting some of these to them). You would think that these are Project Management 101 but you’d be surprise how often and rampant project managers, business process owners and system integrators etc. overlook these things.
I would add one more:
5. Focus on understanding the business and not too much in the technology. Technology alone will never solve a problem at this scale. The more you understand the business, the better you know what the problems are, who are the people you need to solve the problems and what are the ways in can be solved. Technology should not be viewed as universal panacea:
Knowing what the problems are — by knowing the business, problem identifications come naturally. When you know the problem, mapping software features to solve them would be less difficult. Our strategy typically involves immersing our BAs (business analysts) with their existing manual process. It’s a gruelling task but a very important one. Once we are confident enough that we understand their existing process, that’s the only time we move on to the next phase.
Knowing the people you need — domain knowledge engineers are very critical in the success or failure of the project. These are the people who know the business to the guts. They know the pain points. They have ideas on how to solve them (always take them with a grain of salt) and they are the ones who will actually use the solution so involve them as much as possible, as often as possible.
Knowing ways to solve the problems — pure automation is often too complex. Most people just want to do their job and be done with it. Often, this can be achieved by applying what works from an existing process to the new one, even manual process. Case in point, we were asked to add a feature to a certain project where the system would allow them to compose email and send the reports generated by the application. I told them, “Why not just copy the link of the report and send them as a regular email”? After a few convincing, they realised what I suggested makes sense.
This is a little late but more than a week ago, there was ruckus regarding this post from Secret. CodingHorror retweeted it. But this comment grabbed my attention. As someone who has a Windows in his Macbook (VM via Parallels Desktop), this is just downright clueless. If you’re a mobile developer doing enterprise apps, having .NET as a backend is very comment scenario.
Brent Simmons on being wrong in the internet:
But to do that means thinking a little bit differently than you may be used to. Instead of taking feedback as criticism or correction, take it to mean that the process is working. If you learn something or change your thinking, then that’s great. That’s the point.
I couldn’t agree more. The stigma of being wrong is such a huge impediment to self-improvement. Which reminds of this:
xkcd: Duty Calls
The hardest thing for me to do is sitting still, so when I have a chance to do so, I do. When planning my first (real & no-work, no-computer) vacation, I promised myself — I will learn to just sit still.
I feel his pain. Every time we plan for a vacation, the thought of getting off the grid would briefly play with my mind. Then my senses would come around and take it back.