403 karma · joined February 28, 2012
My email is my username @ reenhanced.com. I am happy to receive email from you at any time.
The other commentators here are right, it won't solve a good number of the issues in this proposal, but works well if you need something for developing against subdomains.
It's easy to type and easy to remember and should always do a good job of expressing intent of usage.
Many of the developers I've seen working in this space seem a few years behind, so I'm excited to see this published here. Gives me faith that I'm making the right call (even if it is a bit painful to develop for these things. XML and all.)
Granted, there hasn't been a lot provided in the request. I just find it fascinating to watch the sales process work out somewhat in the open here.
How would you stand out if you were looking to win this?
SEEKING WORK - Pennsylvania, USA - Remote only
I'm the leader of a small team (there are 3 of us) with a long history in web development.
Where I excel is in big picture development strategy through building re-usable pieces, laying one brick at a time. I can help lay a good base for your developing projects that will last for years, despite changes in technology and display incredible endurance on difficult challenges.
I take a long-term strategic view and believe that I only win when you win. No bullshit shiny new tech, no getting lost in rabbit-holes following "the next big thing". The right tools, for the right job and a focus on the results.
Technologies: Ruby on Rails, React, React Native, Swift.
Award-winning developer, with a small team behind me to help achieve even more.
215-804-9408
nhance@reenhanced.com
P.S. While it has nothing to do with my work, I'm an avid endurance sports athlete and endurance motorsports racer. I seek difficult challenges too big to conquer. Let's do the impossible, together. Location: Pennsylvania
Remote: Yes. Remote only.
Willing to relocate: No.
Technologies: Ruby, Rails (back to 1.x), Angular, React, React Native, Microsoft Dynamics CRM, Android, iOS
Résumé/CV: Award-winning developer. Experience since 1999. http://github.com/reenhanced http://buildbettersoftware.com/
Email: nhance@reenhanced.com
I specialize in building software tools to help businesses defend profit margins and competitive advantages. Let's get started with a competitive analysis so we know where you stand. Together, we'll build a plan to help you remain adaptable against the coming exponential change in the world.Start here: http://www.agileasaservice.com/
We then convert those videos into tests that are merged into your repository as a part of your CI process.
Here to the crazy ones.
The faith that big things come from little ones is a bigger factor in success than is often acknowledged.
We need more articles like this! Thank you for your work!
Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebase and lose all work associated with it?
This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash.
We won a Ruby award for our work on Git Reflow. There are big improvements coming this week that can make it easy for teams to tweak the workflow to suit any special needs you might have. It works on github and bitbucket and automatically creates pull requests (and makes sure they're reviewed.) Gitlab support coming soon (maybe this month).
Sounds like there could be interest in a writeup on this
Remote: Required
Willing to relocate: no
Technologies: Ruby on Rails 1.2, 2.3, 3.2, 4.2
Description: I've developed a system and tooling that helps us upgrade old rails apps. This is our only focus and it lets us be more efficient than generalized developers.
We've got a low-priced "upgrade track" that enters your app into our development pool of our semi-automated upgrades. All code delivered by pull requests, with no writes to your codebase.
http://www.railsasaservice.com/
Email: nhance@buildbettersoftware.com
It was able to capture neat videos, but I think a gopro stuck to the helmet would do a better job.
It reads like what you'd expect to read from a charity.
It would be great if we could be perfect, but sometimes small commits to master do have to happen. All we do is make sure we subject every feature to code review and acceptance before it gets to master. If it slips through, then it's technically a new change request in our eyes
Because we don't care about the commits on the feature branches, we prefer doing a regular merge, not a rebase of the feature branch, so that there's no need for force pushing at any point. We consider a force push of any kind to be unnecessarily dangerous.
The tool will handle the merge up for you, but if there are conflicts you'll have to resolve them before you can release the feature.
Is it ever going to help anyone to `git blame` a line of a file and see a commit message like "Whoops, fixed a typo!"? No. But you can't avoid those types of commits.
What you can do is prevent those commits from going into the released history of the product. We develop all new features in feature branches (made _very_ easy with the commandline tool we built for it) and only after code review and acceptance testing do we squash merge it to master.
This lets us put together all of the commits, typo commits, WIP commits and whatever else into a combined commit that contains all of the changes that make up that feature. We even enforce a special syntax on the commit so when you look back in the history, you can trace it back to the code review and to the actual ticket that requested the work.
This means we keep all of our dirty backup commits until release time when we throw them all away in favor of the squashed commit. It makes git blame on any line of any file a sexy experience that provides accountability and an easy way to figure out why the code is the way it is.
Our commandline tool automates a lot of this for us. It's biggest benefit is the tie in with github (and this week bitbucket) to create pull requests and the "deliver" command that handles squash merging and providing the structure for the final commit.
It's all open source and available here: http://github.com/reenhanced/gitreflow/
1: If search is how you access the huge variety of apps, why is the search bar hidden all the way in the top corner? When you open the app store on an iPad, you have a beautiful, but ultimately very limited view of apps.
There really needs to be, and I believe there is room in the market for, a service that helps discover new and upcoming apps. Both Apple and Google do a poor job helping users find apps they might like.
2: "Genius" is useless if you have to find apps you like first. It may help provide limited exposure to apps similar to ones you've tried, but it provides poor results if you don't know what you want in the first place.
3: Each of the categories provides only the "top XX" or "newest XX" apps. This incentivizes a cutthroat market and disincentives large investment into apps. Sure, there is a ton of VC money to chase many different app ideas, but ultimately, successful apps will need to make a return on investment. Both Apple and Google do no favors to developers by fueling the "turnover" game. You get one shot on the "new releases" board, then you're on your own for marketing outside of the app stores. In the long term, this will decrease the quality of apps on both platforms. Amazon has a shot at getting it right, and I believe this strategy may favor them in the long-term.
If you really want to win, find a way to improve discovery or "browsing" of apps. The market will follow the incentives to their logical ends, and right now, both of the big players are missing the opportunity to incentivize discovery of quality.
Nick
P.S. I don't know the solution to these problems either, but look for yourself and tell me they don't exist.
For a company so evil in so many ways, this really surprised me.
Think about this, if this works, low-income households can increase their earning power through learning skills that will allow them to make more money. Once they're making enough, they'll be more stable customers for Comcast and having used the internet to improve their lives, the internet will be one of the last things to cut. (If I was in the position to benefit from this, I'd never "bite the hand that feeds me" if I can avoid it.)
If they don't screw this up, Comcast stands to win hundreds to thousands of new lifetime loyal customers (assuming they don't screw up retention).
Low income families increase their earning power.Comcast wins more business. Khan is more successful. There are no losers.
This is absolutely brilliant. Good job Comcast!
IMO, this is why you avoid investment money. Can you imagine VC "partners" forcing you into a decision like this?
$3 Billion dollars _IS_ changing the world. How much more could you possibly want? What kind of future is preferable to the one you'd have had you taken this deal?
Can anyone make sense of this?