Personally I use Google Photos for that. It's better than Apple Photos cause there's native apps for both iOS and Android, and its web-interface is just as fully featured as the native apps, unlike Apple Photos' web interface that's kind of just a stripped down stream of recently added photos.
Yeah, that is a good solution too. I have tried to avoid Google Photos for some of the same reasons I avoid FB, but I think it is still a huge improvement over FB. Although Gphotos is not too hard to set up, I was compelled when my 82 year old aunt could figure out the stock Photos app herself. No Google account required.
Also, you can view iCloud photo albums over the web too (although I don't think you can comment if you're not loggid in / on a iP([ao]d|hone)!
Back in the pre-FB era, I used the PHP Gallery app. It was so hot at the time--I was the only one with a photo sharing site at my own domain.
For a sort of intermediate approach, there is also Nextcloud Gallery for folks who want their stuff hosted on their terms but with (modern-ish) access and sharing controls. There's also iOS and Android Apps
These tools are good if you have to use Git-Flow. But I would advice against it. In every single company/project I've worked on that's used Git-Flow, pretty much everyone eventually agreed that it was overkil and needlessly complicated. Something like GitHub Flow is much simpler and straight forward, and typically what we've migrated to, or at least wanted to migrate to. Often such decisions need to go through management, which doesn't always go well due to GitHub Flow not having any rules for versioned releases or a hard-copy specification document among other things.
This is where something like Git Common-Flow [1] tries to fill the gap. Full disclaimer, I'm the author of Git Common-Flow. It was born out of my frustration after one too many arguments about Git-Flow vs GitHub Flow and what GitHub Flow lacks. Common-Flow is essentially GitHub Flow with the addition of versioned releases, optional release branches, and without the requirement to deploy to production all the time.
What's overkill about developing features in a dedicated branch, isolated from everyone else's commits? What's complicated in creating a branch, committing to it, and then merge the changes into the development branch?
The issues I have with Git Flow isn't feature branches, it's the develop branch, and the whole crazy merge dance between develop, release, and master branches. It doesn't provide much benefit and more often than not causes confusion and and problems.
What I'm in favor is is GitHub Flow or anything very similar to it, which just has master and feature branches, nothing else.
> The issues I have with Git Flow isn't feature branches, it's the develop branch
What's wrong with that?
> and the whole crazy merge dance between develop, release, and master branches.
I really don't understand your problem. What's so crazy about separating a stable from an unstable branch, and avoiding to push unstable features when you're preparing a new release?
> It doesn't provide much benefit
I see you never were forced to work overtime just because an overzealous manager decided to merge into a release an unstable feature that ended up triggering crashes in a client.
Do you know what's a good way to avoid that problem? Keeping a stable branch, and not confounding a release with the current state of the development branch.
Whenever I see these sort of complains it appears that the only people who complain about the need to organize a project around separate branches dedicated to track main, release and development branches are people who don't have much (if any) experience working on real-world software development projects.
I have no issues with separating the latest greatest development work from production ready code, I just think the way Git-Flow does it is needlessly complicated with multiple points of redundancy.
For example, the master branch is only ever updated when a release (or hotfix) branch is merged in to master, at which point you also tag master with the release version. Why do you need both a tag and a branch pointing at the latest release?
Instead of ignoring tags, why not use only tags to define releases? At which point you can get rid of master as defined by Git-Flow, and rename develop to master, so you just have a master branch. If the release process (QA, etc.) is lengthy, by all means create a release branch from master to avoid a change freeze. When ready for release, create the release tag on on the release branch and merge it back into master if needed.
Also the whole "feature/" and "hotfix/" prefixes on branch names feels pointless. Why not just call them all "change branches"? Anything that changes stuff, is a change branch. And how about we enforce descriptive names on branches like "add-2fa-support", "fix-login-issue", "update-font-awesome", and "change-search-behavior"? No prefixes needed and yet the purpose of the branches are perfectly obvious.
If I'm not sounding like a complete idiot here, please do have a look at Git Common-Flow [1]. I'm genuinely interested in hearing your feedback about it. Again, full disclaimer, I am the author of Git Common-Flow.
> Assumes nobody's changes ever collide or conflict with each other.
I don't believe that anyone using any VCS expects every single commit to be free from "conflict" or "change collision".
In fact, the whole point of using VCS is that "conflicts" and "change collisions" are a given, thus there is a need to use a specialized tool to manage merges and handle conflicts.
> Introduces a fear of refactoring
On who? They have the exact opposite effect.
Have you ever actually used any version control system?
My point was that any branching strategy will necessarily introduce an integration delay. Instead of merging to master every hour or so, the delay is measured in days. The longer the gaps between merges the larger the change set, the greater the risk and impact of merge conflicts.
And, yes, I have! SourceSafe, CVS, StarTeam, Subversion, Perforce, ClearCase, PVCS, Mercurial and Git in (roughly) chronological order by my reckoning. Thanks for asking.
If you're that worried about merge conflicts, isn't the real problem that you haven't refactored enough for SRP? If two people are working on different things, they probably shouldn't be editing the same code.
I haven't used Flask (or Python) aside from one small hack project. It seemed simple and straight forward enough, and very similar to Ruby's Sinatra framework. Personally in Ruby I would most likely pick Sinatra, in Python I'd pick Flash or something similar.
However if you wanna play with languages you're less familiar with, I'd recommend Go, or Node.js.
Personally I find Go really interesting as it's quite different from the languages I normally work in, and it's concurrency model makes it performant without being a mindfuck.
Node.js is interesting as it's Javascript, but extremely I/O performant due to it's evented nature, but that also makes concurrency a bit of a mindfuck at times.
Those are my suggestions at least if you're itching to get your toes wet in some new fun languages :)
I actually went through the Golang quickstart before writing my original post. It is very tempting, but I'm concerned it might be a long journey for what should be a simple app. In your experience, how productive is Go at kicking out basic CRUD APIs?
I haven't built a full CRUD app myself, mostly some small hacked together tools and various silly stuff. Personally though I did end up just experimenting with basic stuff to get familiar with the language and tools for a couple of evenings before I got anything even half-useful done.
So I'd say, if just want to get a simple CRUD API app out quickly, use Python and Flask or something similar as it's something you already know well. If you wanna use the CRUD API app as an excuse to play with new languages and technologies which will hopefully lead to a expanded skill-set, then go for Go ;)
As for Node.js, if you already know Javascript, it'll fall about 30-40% of the way between using Python that you know and Go that you don't know.
I was recently in the same situation as the author of this post. And as far as I can figure the reason HTTPS is disabled, is that the BT Wifi hotspots require you to login with username/password on a custom page before you can access the internet. Most people's default thing to do is google something, which then redirects them to the BT Wifi login page, but this only works if Google is being served up via HTTP, otherwise BT wouldn't be able to hijack the request and redirect you to the login page.
Hence it's probably not got much to do with privacy, and more to do with usability.
If +90% of users just got HTTPS/SSL security warnings from their browsers instead of a BT Wifi login page, they wouldn't be able to use BT Wifi unless they're of the minority who know and understand how HTTP/HTTPS connections work.
It's worth noting however that both recent Windows and Mac OSes at least detect captive portals automatically and show the login page themselves, making elaborate and insecure hacks like that unnecessary.
That is true, but everyone aren't running even recent-ish OSs. Also having relied on BT Wifi for about 2 weeks recently, I can definitely confirm that OSX's detection doesn't always work. About 80% of time, it's fine, the other 20% it's google for "asdf" and get redirected.
Also, BT Wifi tends to log you out every 20 minutes to 6 hours seemingly by random, forcing you login with your credentials again, and this need to re-login is something that OSX never detected.
Isn't that a security hazard? The mechanism of these captive portals is literally a MITM attack, and I don't see how to distinguish a benevolent from a malevolent use of it.
Personally I know the pain of creating a CSV parser. In late 2006 I was working on a PHP project that required a CSV parser, and what was available at the time did not come close to cutting it. So I created my own parser/generator, which among many other things included automatic delimiter character detection. It was a rather painful project to create, but I learned a lot, and found the experience really fun.
Overall I agree with the article, there's no point in reinventing the wheel if there are libraries out there. And CSV specifically is a horribly complex format to deal with. But sometimes rolling your own is the best and/or only choice you have, and you might come out the other end enjoying the experience, and having learned a lot.
As for what happened to my old CSV parser? It ended up being quite popular, but stuck in the dark ages as I'd mostly moved on from PHP years ago. But thanks to a contributor, we've recently put renewed effort into bringing the project in to modern times: https://github.com/parsecsv/parsecsv-for-php
Personally I have to visualize the person's name in my mind written out in plain text, then I remember that visual image of their name and associate it with an image of their face.
This isn't a technique I read about somewhere, it's just what my brain has been doing at least since I was 7 and learned how to read and write.
Typically when I try to remember someone's name, I'll see the first letter of their name in my mind and it's enough for me to recall and say/write their name. Other times if I'm having difficulty remembering their name, given some time (5-60 seconds typically) I can generally recall their name by reading the image of their written name I originally memorized. Often this reading is more of a hint towards a the concept of a common name I know of (like Alex, John, Maria, etc) meaning I don't need to recall and read it letter by letter. While if it's a more uncommon or obscure name (like Agnomemnonas, or Urania) I generally have to recall and read it out letter by letter.
Personally I think it ties into the fact that I memorize everything in a visual and three dimensional way.
I tend to have conversations about how people remember names, specially with new people I meet, and as far as I recall, I've only met one person who memorizes names in written form in their head. However a lot of people I've met tend to not remember people's names till they see them written on paper/screen, so they'll try to write people's names down at some point if they don't get a business card with the person in question's name written on it.
Okay, please excuse my ignorance if there's something I'm missing here.
I understand the problem when it comes to saving, and the issue of dipping into savings when you shouldn't. But I really don't see the point in a service like this, at least not personally.
There's three main issues I have with it:
1. Why should I let some random company I don't know or trust keep my savings for me? I would assume you're not a actual bank, so should you go bankrupt there's no government insurance that'd ensure I don't loose my money. And not saying you would, but from my point of view, what's there to stop you from taking the money and run?
2. A charge of 3%. So to save £100 I'd loose £3. If I was saving for a Retina MBP of around £2,500 I'd lose £75.
3. Interest. Ok, sure, banks pay pretty horrible interest, but still, I'm loosing out of money I would otherwise have gotten. I saw your response about working on providing interest somehow in the future, but I'm focusing on the now here :)
When you add it all up, the increased risk of losing all the savings, combined with the loss of money in the 3% charge and lack of interest, personally I really see no point in using your service compared to my bank's savings account.
And ok, it's easy to move money out of my savings account, but it's supposedly easy moving it out your service too. If you were to change that, there might just possibly be some point to it compared to a savings account. Except then you're treading on dangerous legal and/or moral ground if you deny people access to their money, even if they've previously agreed to the terms.
On a final note, I believe the only valuable feature you have to offer is the fact that friends can chip in. If I were you, I'd focus on that feature instead of holding people's cash. Let people set up some kinda campaign page for their new phone/laptop purchase and let family and friends chip in, wiring the money back to the user, rather than you holding on to it. Think of it like a personalized kickstarter mashed with amazon wishlists or something.
<rant>Let little Jimmy Neutron setup a campaign for his wish to get an Xbox One. He's got £200 cash already, which the campaign reflects, then he sends the campaign page to his grand parents, uncles, aunts, etc, and maybe they'll chip in enough so he can get his new console.</rant>
I got my first computer when I was 15 (in 2001), and after 8-9 months of just playing video games I ended up playing with HTML in Dreamweaver. Over the next year that'd expanded to include CSS, JS, and PHP.
Between the age of 16 and 22 I primarily worked as an IT technician while programming on ever more ambitious projects on my free time. The most ambitious of then was Zynapse, a VERY Rails-like PHP5 framwork I started in 2006. It had i18n and other things from the start, which Rails didn't gain till years later. I never finished though, so uploaded it to Github as-is 4-5 years ago: https://github.com/jimeh/zynapse
When I was 22 and moving to a new city I decided it was time to get paid for programming. Specially since where I was moving to actually had big companies employing programmers, compared to where I used to live there was no local businesses at all hiring programmers. Hence I probably could have started professionally programming earlier if I had easier access to programming jobs.
The first programming job I got was for a Rails shop, so I spent around 10 days familiarizing myself with both Ruby and Rails before they let me work on any real-world projects.
It's now 5 years later, and I live in a much bigger city (London) in another country, and I'm still programming for a living.
As for how I learned to program, it's all been self-taught based on what the internet has to offer in terms of source code, documentation, blog posts, books, and generally just playing around with things to see how it works, and what's the best way to do something.
I should also note that to this day, I haven't actually finished any of the programming books I've started to read. I always end up skimming through them instead to pick a few really interesting things, and then go back to my general goofing-around-for-fun kinda learning style or whatever it might be called.
But as far as I'm concerned you definitely don't need a CS degree or anything fancy to program for a living. I'm sure it helps a lot if you do, but it's definitely not required. You just need to be curious, interested and have some spare time to learn.
P.S. Sorry for not adhering to the 1, 2, 3 structure of your question, I might have gotten a bit carried away :P
No worries for not adhering to the structure, it was just there because I wanted to urge more than "Yes"/"No" replies, I enjoyed reading your post. Very cool story.
I'm self taught at the moment, about to go to a dev bootcamp to really solidify my understanding of web-centric ideas (most of my stuff has been data crunching). Glad to see that so many people are happy in the field without a CS degree.
