Edit to add the esdiscuss mailing list if you want talk about the language itself, although it has been dying a slow death in recent months as the authoritative voices of old seem to avoid it now:
Just a few weeks ago Pluralsight circulated an email on Udemy telling us, Pluralsight authors, that the two companies have met as Udemy has acknowledged the piracy problem and pledged to take down any flagged courses much faster in the future.
I don't know if there is a relation to that action and this takedown until an ID check, but there might be. Also, if you think about why they took it down immediately until you verify your ID: if someone flags this video and it is indeed a copyright infrigment, Udemy could be sued for not acting immediately.
I do empathise that takedowns without notice are painful when you're not the author - however as an outsider I am glad that Udemy on the other hand is starting to take piracy of courses more seriously.
You are not entitled to anything on their platform, and this seems like an honest attempt to combat piracy (which actually protects content creators such as yourself).
Maybe it was spot checked because affiliate marketing is often so closely associated with spammers and scammers.
My wife came along and showed me though that there is more to life than programming and I have to thank her for that. She's a wonderful gruf woman who changed my life. I still code at night on occasion, but not very often. I've got better things to do. I really believe I am happier for it.
All that said, are you entirely sure programming is what you want to do the rest of your life? After a long day of coding I need to be ripped away from its siren song or I'd simply never stop, and I know a lot of developers that feel the same. The job takes a lot from you, imho, and it sounds like you may not enjoy it enough for it to be worth its cost.
I do all these things because it's what I'm driven to do. I would go crazy without it. There's no shame in not being like me. Do what you enjoy.
I am not as prolific as many of the people you are probably thinking of but I am slightly above average. Here are a few things that WORKED FOR ME:
- Learn & use GTD - life changing. I use omnifocus but you can do it with pen & paper
- Automate as much as you can - checkout keyboard maestro and many other tools
- Use your calendar efficiently - block time for reading, playing, OSS or whatever
- wake up early
- excercise (i don't do too much but the days I do, I feel great)
- keyboard shortcuts for everything
- look for productivity tips for whatever tools you are using.
- turn off facebook and distracting material
- monitor your time - I use rescue time
- outsource as much as you can. I use fancyhands.com to handle things like calling the phone company, cable company, making appointments and so on. It saved me tons of hours of BS tasks
- I have had some success with the pomodora technique as well, give it a shot.
- Don't work more than 8 hours a day
- Work from home as much as you can
- don't burn out
- for side projects, blogging, oss or whatever it is you want to do, i find it better to do 1 or 2 hours a day than try to crank 8 hours on sunday.
- spend time with friends and family - it's amazing how your productivit improves when you are refreshed
- take a power nap or naps
- sleep well
I am married with infant twins so I try to be as efficient as possible with the limited time I have infront of the computer. 1 hour of highly focused work yields more output than 4 hours of distracted, half-ass work.
forgive the self promotion but I think it is relevant. I put together a free ebook about mac productivity tips - might not be as helpful for techies like you but you might at least learn a trick or 2 or find an app that you never heard off - www.bestmactips.com
Being a prolific developer doesn't have as much to do with talent as people might think - Developers become well known by blogging, speaking at multiple conferences or just being in the right place at the right time (whilst making lots of open source contributions).
Also, famous developers tend to own/maintain many (often several hundreds) of different open source projects instead of focusing their energy on just one project. There are rare exceptions like Solomon Hykes of Docker - But if you just made one popular open source project, then that's usually not enough to be known in the community.
Also, where you live makes a difference. Your odds are much better if you live in Silicon Valley. I know a developer who created/maintains about 5 projects each with 2000+ GitHub stars and he is still not well known because he doesn't benefit from network effects like devs who are living in the US.
Here's the answer you are looking for: https://github.com/sindresorhus/ama/issues/167 and you can search more related questions in the issues.
Other than that, maybe you could try pulling back the number of hours you're at work. I've felt myself getting stuck in that cycle of work, eat, sleep in the past, but I am currently pretty happy with my routine.
If you want to make some life changes, I'd recommend starting small. Pick one thing to improve this week (don't eat less than 2 hours before going to bed). Then next week try adding another thing. Before you know it, you'll be doing these healthier things without even thinking about it.
From personal experience think that programming pretty much crashes and destroys your personal life when you really, really want to go above the rest.
Everything changes, except you and your computer.
I remember when there was no computers. Existed more beer, fun and happiness. But at the same time didn't felt as happy as getting something epic solved.
Maybe one day it looks as it is all worth. Maybe. Enjoy your life OP, you only get one.
But life is not job or software development and you shouldn't sacrifice it to computer programming even if it is a passion and you love doing it.
One day you will leave this world: will you regret you should have worked more or will you regret you didn't live your life?
However, I came down to the realisation of several things very quickly.
1) Something in my brain causes me to grasp new concepts quite slowly, no matter how interested I am in the subject. So it takes me longer to work through things.
2) I also enjoy my family life, so it comes down to searching for time after the family has gone to sleep or before they wakeup to do some tech stuff. Kids are still a bit young to do tech stuff together.
3) There are only 24 hours in a day and I wont get any more days after I dead. I want to allocate some of the hours away from tech and experience humanities.
Sorry, I am sorry that this does not really answer your question, but I think that this side of the coin is important as well.
My advice is to find a job that you really, really enjoy doing. Once you have reached there, give it all you have got during the working hours. Your social life will thank you for it.
There are a couple of important points I've learned along the way that might help you:
1) Some people can code productively 24/7, but those are very few and far between. For starters, they have the skill to concentrate hard for a long time and work in an environment where that is feasible. It's not feasible if the next cubicle over has a sales person in it who spends ten hours a day on the phone. Second, most of them tend to do it in bursts as it's extremely hard and draining to sustain that level of concentration and effort for hours and days on end. What you see is often the output from the bursts, but you don't see that they're then spending a fair amount of time doing different things so they can recharge their brains.
2) It's easier to do this when you're young and pull a couple of all nighters a week. This makes you a hero, especially in places that thrive on hero-based development, but you have to realize you're burning the candle at both ends. As you age and build up experience, you tend to be more productive simply because of your experience, but you're also not necessarily that willing and suited to pulling 16 hour days for extended periods of time.
3) Most importantly, your brain is a muscle. Exercising it improves its function much like exercising your body improves its function, but it also needs rest. If you look at the way top athletes train, they push themselves hard but they also allow for sufficient rest periods. It's the combination of exercise and rest that leads to the improvement. Take one or the other away and you either overextend yourself (and injure yourself) or you don't grow as much.
Yes, I read about programming and play with languages during my off time, but I try to satisfy my need to build things (which is what initially drew me into software) by working on physical things instead. Things like building/restoring a car or motorcycle, gardening, working on the honey-do list etc. Oddly enough they're not too dissimilar from programming as you still end up solving problems.
TL;DR - find a way to switch off, be it through meditation or whatever else works for you. Get enough rest and exercise the other parts of your body. Learn to recognize the signs of burning out and stop the journey before you get there.
I suggest you read Coders at Work if you haven't already. It is a good compilation of interviews with living legends of computer science and famous software projects, and the interviews give insight into how each approaches his/her life. You might find some of it inspirational and insightful.
Great advice for time management, works well for IT positions.
Exercising is for sure a net gain in time. It makes you feel healthier, happier about yourself, and helps you think more clearly.
Here's me: https://github.com/andrewrk
I have a JIRA for everything I do with customized workflows, and among many other projects I built this:
to mail me when subjects interesting to me come up on HN.
I recommend reading 'Getting Things Done' and working at your own pace. Focus on the things you're motivated to do, not what you think you should be doing - that's what a paid job is for!
It is best for the single and young because it requires you to immerse yourself to learning, to solve problems and face difficult failures, it requires routine, and dedicated energy to learn, requires energy to go to the workshops/meet-ups/groups and be updated when new learning opportunity arrives. It requires spontaneity to still be interested in other things in order for you to refresh your energy.
I think the lesson here is that some people put their craft at the center of their life and make it the focus of every single day.
B) Look to your health. If you want to be more productive without "paying for it" later, you fundamentally need to increase your ability to produce. Eat right, exercise, practice good sleep hygiene, etc.
Stop wasting your time reading/posting/liking on sites like HN, Facebook, etc.
On weekends, I experiment with making music, reading, playing in the snow, etc.
1. Get enough sleep. You've only written three paragraphs and there are already a lot of suggestions that you need more ("I don't feel as productive as others", "I just drop dead in bed" when well-rested people usually take 15-30 to fall asleep, "I felt like I was inches away from becoming part of the zombie horde.")
Coding pretty intensively uses your short-term memory: "I need to take this query which I prepared above and execute it on those variables, wait, this key from the database gets renamed to that on the front-end, okay, test it... dictionary does not have the right key on line 189? What's over there? Oh, I forgot to do this critical preprocessing step, jump back to my code, 3 lines before, add the function call, test again -- what the crap is that, switch back to editor, aha, missed a semicolon here...". Each of those actions requires you to not be overwhelmed by the number of details you have to remember, whether it's where your tool for testing is located, or what the preprocessing function was called, or what have you.
When you're even a little sleep-deprived, your short-term memory decreases dramatically -- if most normal humans can only juggle 7 balls (7 big details or crucial tasks occupying their memory), missing a few hours of sleep brings it down to 4 or 3. So of course everything looks two times bigger.
Sleep deprivation also causes you to lean on substances like sugar and caffeine, and those substances tend to cause procrastination "I'll browse Reddit until this kicks in" -- until their effects wear off and leave you right back where you started with a bunch of nothing done. You can mitigate this somewhat by giving yourself a short task to do before the caffeine kicks in, even if it's an asinine one like "write down what you want to do today." Speaking of the which...
2. Write shit down, set alarms, otherwise use harebrained tools.
Those 7 balls that you can juggle need to incorporate just about everything that is happening in both personal and professional life -- not just code. If those things are in the mix, then you're not as effective. Just like how you should set an alarm for "time to start brushing my teeth and getting ready to go to bed" so that you can get enough sleep, you can set an alarm for "at this time I need to stop everything and call the couch company to send someone to fix the couch at home." Write those things down somewhere, set an alarm to look at that list and do the things on it.
3. Kill context-switches. Either lie your ass off about them or say "no" up front or be honest -- whatever is necessary to kill them.
Take your hands, open them in front of you, spread out your fingers, interleave them. That is 8 work tasks spread out over some distance L. Maybe it's 8 hours of the day working on two projects, Right and Left. One gets concluded at 4pm, the other at 5pm. We'll assume you got started at 8am and ignore an hour for lunch.
Now separate your hands and collapse your fingers. Put your right hand above your left hand, touching. Still 8 fingers in a row, but now you notice that your Left project is released at 12pm before lunch, while your Right project is still released at 5pm after. You just improved your average time-to-completion by 2 hours with no stress, and no improvement in efficiency: you just rushed one project out, then focused on the other.
Now interleave your fingers again and remember how each of those switches between projects feels. You've got 7 in there, yes? Each one doesn't feel good, does it? Because you've got to stop juggling one set of balls, put it all down, and slowly start juggling this other set of balls. Each context switch eats up mental energy. (It also eats up time -- if you need 15 minutes to really get up to speed, then the 7 context switches eat up almost 2 extra hours of your day. So there is an undisclosed efficiency gain here.)
If management forces on you to be working on the two things at once with constant status updates, strongly consider lying your butt off. (Of course, first show your boss the trick with the fingers, it usually convinces them.) Because if management is asking you to do worse work slower so that they can be polite to two of their separate clients, then management has failed. They're supposed to buffer you from all of that crap.
If you can't lie and you can't convince your management, try a firm "no." Just say "I'm on this high-stakes Project Left right now, I can't take on Project Right right now, maybe when Project Left is over I can. Fortunately I think Project Left will be done by end-of-day today, possibly before, so if you really can't find someone else, I may be able to start Project Right today." A "no" always goes better with a nice timetable that suggests that the task will still get accomplished in a timely manner.
Similarly, ignore those "trends" when you're coding. Trends are another project with another context switch. Don't interleave it with anything else.
The answer, then, is to find a way to work on these projects in the course of your job. That's what I do, and my best guess is that that's what the people you've heard of do as well.
Find some project that your employer really, really needs, get permission to open source it, and spend your most productive waking hours on it.
Exercise helps like everyone is saying.
Recently I read a book called Pragmatic Thinking and Learning. Great tips in there.
But don't worry about 'being one of those people', just try to do what like/love. And if you don't know what that is yet, find out!
And exercise, best way to clear your head!
Great phrase - I'll be using that !
$ bundle exec gem list |grep i18n i18n (0.6.9) $ bundle exec gem update i18n Updating installed gems Updating i18n Successfully installed i18n-0.7.0 Gems updated: i18n Installing ri documentation for i18n-0.7.0... Installing RDoc documentation for i18n-0.7.0... $ bundle exec gem update activesupport Updating installed gems Updating activesupport ERROR: Error installing activesupport: activesupport requires i18n (~> 0.7) Gems updated: i18n, thread_safe Installing ri documentation for i18n-0.7.0... Installing ri documentation for thread_safe-0.3.5... Installing RDoc documentation for i18n-0.7.0... Installing RDoc documentation for thread_safe-0.3.5... bundle exec gem update activesupport 23.83s user 0.30s system 98% cpu 24.521 total $ bundle exec gem list |grep i18n i18n (0.6.9)
Another decent resource for getting up to speed was the Stanford iOS course videos.
The tutorials from Ray Wenderlich (http://www.raywenderlich.com/) have been massively helpful to me.
- Don't work with a friend on a startup. You are very unlikely to be friends afterward. If you can't easily compromise on something as unimportant as your stack, you're going to disagree on way more important things. Why do you need two devs anyway?
- Two things that kills startups are analysis paralysis (always trying to make the perfect choice = wasting lots of time) and being afraid to leave your comfort zone. Both of you should be willing to use the other person's stack because it will end this pointless argument and also help you learn something new (and possibly something you like even better than what you're using now).
- If you're using Angular, you have an objective reason to slightly prefer Node: it allows you to use a single language on the front and back ends.
- One possible compromise would be to use TypeScript, which was created by the same guy who created C#, so it shares lots of the same philosophy. TypeScript is also the native language of Angular now, so you can use it on the front and back ends.
- Another possible compromise would be for one of you to work on the back end only, and the other to work on the front end only.
Focus on validating the problem first. Get people to pay you to solve that problem and once you have people begging you for the solution, then figure out something to build.
I've seen (and experienced myself) this mistake too many times. The tech stack does not matter AT ALL.
All that matters is that you're solving a problem for the people that will pay you. Don't spend 3 months perfecting the ideal tech stack and then realizing you have nothing to use it for.
With that said, you need to divide responsibility. Either a 'CTO' role that has the decision to base the stack in his/her choice, or divide the tech up frontend/backend and give one person authority over each.
When it comes to tech decisions, look at what you can work on fastest, secondary considerations can then be things such as your immediately available hiring pool, and what would gel easier with those people, and finally things like licensing.
Strictly pair program the implementation to facilitate quick knowledge transfer of the tech stack.
In the early stages, it is about finding a minimal solution to fit your value prop so you can get people to engage with it and validate your assumptions. This requires more thinking than code. Pairing the implementation will not only allow tech knowledge transfer, it will facilitate those important idea discussions that need to happen too.
In the future you may have ancillary services/apps better off using a separate DB for performance. DB licensing costs will influence your design decisions so remove those costs from the equation.
C# is fine though (even on linux) and will give you reasonable performance, likely better than node.js is most cases.
As developers we think picking a tech stack is an immensely important decision for the foundation of your company. It isnt. As developers you should be competent enough to pick up the slack and learn new tech as needed quickly, and leave the extra cycles to pick up things that you suck at but will need to figure out: customer services, business model, etc.
Echoing what other commenters have said, if youre already running into problems about decision making then its likely to get worse. I also think youre optimizing for developer happiness way too early.
Then, if your idea works out, you're going to learn a lot and gradually replace all the code anyway. Wait to decide then. This is the one to throw away.
Furthermore, it may be worthwhile learning each other favorite stack as you could pick up new skills. Could be a bonding experience as well. Just my two cents.
I suspect C# /.NET / MSSQL / Windows servers will be higher. In addition to server costs, someone has to pay for those software licenses too.
Just do your product.
If a stack shoes some limits when scaling or anything else along the way and if your startup is still viable, then you can plan a migration with all what you learned to back your tech choice.
Personally I'd go with a universal React.js on Express (snappy SPA for users, crawlable server-generated html for googlebot, with one codebase) talking to a .NET REST API.
Then later you can use React Native for mobile and the same REST API. Or an Electron.js desktop app talking to same API.
PostgreSQL matches MS SQL Server in most regards, but MS SQL Server kills it for text search, but PostgreSQL does row security, and is, you know, free.
On the side note, I highly recommend to try Meteor (www.meteor.com). I was in the same spot a year and a half ago and when we tried Meteor, we didnt know anything about Node but Meteor was so simple that we just went with it and never looked back.
I also have a feeling that the "report spam" button loses its effectiveness after awhile. I went on a report-spam-spree a few months ago, but Google seemed to ignore half of my reports and still delivers those senders to my inbox. Frustrating.
Plus the strength of this approach is directly proportional to the level of reward. Without knowing what a person 'wins' if they successfully bypass your check, it is hard to know if the check itself is strong enough.
It ultimately isn't that hard to make a fake account and add three other random/fake accounts. Takes about ten minutes. Then wait a month. The question is, is the reward worth the hassle?
I don't have a better/alternative way of doing this. Online age verification is an on-going problem, and gender verification is a pandora's box (in particular related to LGBT issues).
Since gender is relevant, I assume you're making either a dating app, or an app that feeds into some sort of beureacracy. If the former, then people have an incentive to enter their real gender if they want to get any use out of the app. Linking to Facebook is a bad idea since people are usually kinda wary of linking their dating profile to other social media. If the latter, then facebook is not going to satisfy your stakeholder. You should consider asking for some form of ID or credit card.
A user who posted before the New Year regarding his financial situation is someone I quickly found myself aspiring to. I didn't have alot of work for him but he was more than helpful for my project. After I learned a bit more about his background, family situation and journey to getting where he is now, I felt compelled to try to help him more.
During one of our many conversations I casually mentioned how my funded startup is suffering from an influx of chargebacks and fraud purchases. I regret not mentioning it sooner because this it was a problem we have been struggling to solve and in no time at all he solved it. He helped us and showed us some of the "carder tricks and tips."
Unfortunately because we (startup) are bound by certain financial regulations we couldn't hire him full time because of mistakes he made as a kid. I know he is still looking for work. I urge anyone who has any kind of work to contact him, I know he could desperately use it still.
Post in question is https://news.ycombinator.com/item?id=10813746 and here is his follow up for anyone who is curious. https://news.ycombinator.com/item?id=10921576
cperciva was making a few "bold" statements and sanj replied "Did you win the Putnam?" to which cperciva replies, "Yes, I did." and later goes on to gloat a little bit saying, he considered his earlier score of 53 his most impressive considering he was 14 at the time.
A user called dbosson proceeds to calls him out on his gloating and talks about helping others. He replies with this: https://news.ycombinator.com/item?id=35120
The thread: https://news.ycombinator.com/item?id=35015
It was one of the few times I've seen News.YC/HN delve into the usual internet forum banter and not being disappointed with it.
You might know of cperciva also as the creator of Tarsnap. He's very open about not being money-driven and the service continues to keep to its roots as a product only made for technologists. He's not concerned with developing the product for Enterprise, nor marketing. He's also someone who hasn't bent to external pressure to further develop his product for anyone else. Everyone else is business-minded, the likes of patio11 included, who are practically screaming for him to take advantage of his brand and following to build up a company.. But he just doesn't want to.
To me, he's someone who's truly gifted, not humble about it but doesn't gloat in such a way that you feel like he's going overboard. His claims are valid, he's matter-of-factly saying statements that are all true. Akin to McGregor, a UFC fighter who always seems to predict how he'll put the other fighter down in the interviews: https://www.youtube.com/watch?v=jJeziuaShow
Sure there are an insane amount of people here I can admire and I follow incessantly because they're such valuable sources of knowledge. But cperciva especially I can respect, because he just doesn't seem to worry about whatever anyone else thinks or expects from him.
This guy is a successful businessman, and provides so much value with so much of what he writes. For free. Go read his stuff, I dare you.
None of them comment here much these days. This is natural as HN has become a much, much larger and more mainstream site.
Interestingly, it's not like the shifts away from Slashdot and Reddit, where there's a new forum where people have moved to (except their own personal communities). If there's a place that has sucked up most of the conversation, it would be Twitter.
*EDIT My comment is in regards to casual conversation as that is how I read your question, originally - if you are asking what to call yourself in business situations, a more formal title may be appropriate thus my comment is irrelevant.
I also appreciate rankam's comment about labels and whether or not they matter. I've tried not to overthink my part-time work as the work has been steady so far. However it seems prudent to come up with a description or tag line going forward. Early work has come through friendship which may not always be the case.
Your second condition would make the license a proprietary licence (it violates freedom #0: the right to run the program as you wish without restriction). In addition, I'm not sure that it would enforcible with current copyright law (similar to the provisions in the AGPL), since I'm not sure you can argue that input data to a program is something that you could restrict in law (and if it's free software, the end user can modify it to allow you to break that rule). And it would also be a minefield (what if something could be patentable, or is patented by someone other than the person who distributed it, what if the patent holder gave a patent grant to the rest of humanity, how many requirements are there for such a grant in order for it to be allowed, etc).
The second provision isn't just unpalatable, it's dead in the water. Lots of SaaS companies host anything and everything without knowing what they host - think Dropbox. Even if they wanted to comply with this provision it would require someone poring over everything submitted by a customer and making the determination of whether or not a patent might apply isn't a determination even an army of lawyers could confidently make.mforther with more and more companies getting encrypted data from customers, this is even more impossible to comply with.
go straight to the point and stop.
Put yourself in their shoes. At the beginning they don't really care about your team nor about anyone else's problems. They care about their own problems, so don't be generic and say "80% companies have this problem". Say something like this when possible:
"You have this problem since 2014 and it costs you over 400k EUR/year, here is how we can solve it for you".
For this to work, it needs to be targeted for that specific big company.
If you really need to be more generic and explain what you do and how big the market is then do it, just remember that the human attention span to hear you will be around 90 seconds. And they will only remember the first 10 seconds and the last 10 seconds of whatever you say.
So, score points by getting in contact with the potential customer to investigate real values (talk with an engineer, someone in management, etc). If you know nobody, usually what I see working is picking up the phone and calling the company. You will talk with their secretary, if you are sincere and explain what is happening she might be able to connect with you with the person that can help you succeed (preferably not the person in the audience watching your presentation).
Don't show animated slides. Only show 3 to 4 slides. Might seem hard but reality is that you don't have much attention from them anyways.
When concluding the pitch, end with something memorable such as "this is the type of thing that we are good in solving, come and talk with us after this presentation"
Good luck OP.
Without knowing your product it's hard to give you the best advice, but here are things that worked for me in the past:
* Use real data that they can relate to. For example, if you're software does case management for non-profits. Find out who their customers are and create an "fake" example of how your software would work to manage a case for that company, from start to finish. This is partly for the 3 minute presentation, but more so for the barrage of questions you'll get asked afterwards once they like what they see. It's always easier to sell something when you find a solution to a pain your customer has right now, with one of his customers!
* Use only the terminology that they use and understand. Similar to #2, use the language that your customer speaks. Know your user and which language and acronyms they are using on a daily basis. I've seen so many times young startups use scientific terms or executive mumbo jumbo that the audience didn't understand.
* The 3 minutes is only the beginning. Whether you succeed or fail, it's not the end. Before, during, and after, identify the lead of the group that will be using your software and try to identify the decision maker. The person who signs the check if often different then the person evaluating your software. This is a sales cycle and they are both important for you to convince. Get a meeting with them, figure out what makes them tick, what their budget is, when will they be in a position to evaluate your software, etc..
Hope this helps a little, good luck!
Your goal in the first meeting is to get the second meeting. Thus, it doesn't do you a lot of good to have them think they understand what you offer (especially if they get it wrong). You want them to need to talk to you before they make any decisions. This all points to focusing on the problem and convincing them that you _can_ solve rather than explaining how you solve it.
There is a subtle technique known prizing. Subconsciously, you must convey to the audience, "You are trying to win my attention, I am the prize, not you. I can find thousands of buyers/clients like you. But there's only one of me." You control the Frame.
On this subject, Oren Klaff is the Master > https://www.youtube.com/watch?v=YSYWFRfPUs4
I've used them all without issues, but service can be really slow / even a hassle to deal with.
It goes over most of the things you would want to know. Plus, yeah, Luminus.
After that, I would go to the clojure docs to get started with web dev in clojure:http://clojure-doc.org/articles/tutorials/basic_web_developm...The luminus framework has a good tutorial to get started as well: http://www.luminusweb.net/docs
Caveat: I do not code clojure as part of my day job.
In the meantime, for the basics, I started with the Koans. http://clojurekoans.com/ I found them a largely excellent way to get up to speed with the language by doing some actual coding.
I don't know your use case so I might be wrong, but I believe your mistrust in Github and Bitbucket is unjustified.
As far as encryption schemes go, everything depends on what or who you're trying to avoid.
What do you need and what are you worried about? A local git repo backed up to Tarsnap is pretty secure and unlikely to lose your data, but may not fit your needs.
I have some experience with using events to construct the final state for data analysis. (If you didn't mean for data analysis, just ignore this comment) The problem with trying to reconstruct data at some final state based on events is that the meaning of the events change over time. For instance, createUser might do one thing in January, then something slightly different in April (e.g. sets a default value to be 10 instead of 5). It becomes a nightmare to try to get the final table to be accurate, and if you try, your reconstruction script ends up with a bunch of if/then cases based on the history of the program generating the events.
You still probably want to log the events, but it looks like you are hoping to recreate the users table based on your createUsers history, which would run into the problem I mentioned above.
If you do log data straight to files, you can always analyze it with something like Splunk or Kibana (and if you use Kibana, you probably just log the events with the ELK stack). Still, it's way easier to analyze data with a relational database because of the tools built around SQL, and it's already familiar to analysts whereas Splunk's proprietary language is something they'd have to learn.
If you end up using SQL, I suggest https://aws.amazon.com/redshift/ for the data warehouse, and http://DataDuckETL.com/ for getting the data into Redshift.
Secondly here is an interview with a notable type designer - Ray Larabie, https://www.myfonts.com/newsletters/cc/200905.html Which might be an inspirational.
Hope that helps.
In the spring of 2009, as a senior at university, I was one of the first few people involved in the movement that became Twin Cities Maker, now a hacker/makerspace in Minneapolis, MN.
Movements start small. The very first meeting was just three of us meeting in a coffee shop after one guy started by boldly registering the web domain and looking for interest.
This eventually grew to a consistent weekly social meeting in the back room of a coffee shop. Over time informality gave way to an official club with officers. We started collecting dues to save money for a lease while still keeping the energy by meeting every week at the coffee shop.
I moved away for work soon after graduating in the summer but initially kept in pretty close contact with the group. By January 2010, with the help of a group-merger, Hack Factory of MN dba Twin Cities Maker officially held a lease to a space in town. Since then they've expanded to lease more of the building. At the Hack Factory you can tinker with electronics, 3d printing, CNC routing, milling, welding, woodworking, textiles,....
Even after acquiring the shop, the weekly coffee shop meet turned into a weekly open house on Wednesday evenings that still runs today.
Credit for this success goes to the individuals who stepped up to volunteer running this crazy enterprise. I have crazy amounts of respect for everyone who's served as an officer or otherwise helped organize things.
After returning to town in 2011 I officially rejoined as a member, although I happened to loose much of my enthusiasm for social tinkering. I was interested, but not committed, so i'd sit in on board meetings but not actually run for office. Eventually, I spent less and less time at the shop.
Since then I've always felt odd talking about my involvement in TC Maker, because other than being one of the first few people in the door, I never personally took much of a real lead role in the organization. By 2013- I was considering myself to just be the longest dues-paying member who actually participated the least.
I'm on another "hiatus" now as I moved to Helsinki, Finland last spring. I'm still on the mailing list, and I still admire the group for doing their own thing and making it work. If I'm ever back in MN and it's still around I'll undoubtedly be involved again at some level.
The Linux distros, for all their good, requires too much handholding and prodding to get a productive desktop development environment working. Windows, too, requires too much handholding, and you're liable to just use a VM for development.
Luckily it was an easy process to switch to something that works much better and without Apple brand telling me how i need to work and to see the world.I'm not coming back to Apple laptop.(Apple iPhone is totally different and perfect device).
If I need to do Linux development - I use dedicated server / SSH and whatnot.
--- Back to your question - some environments do require Apple hardware and cultural fit could be an important factor to blend in and not be criticized.
- powerful Unix-like shell and internals for when developers need to work
- no-brainer UX when developers do not want to have to work
With some bonuses such as:
- retina display that doesn't mess up every other app's windows
- a trackpad with multi-finger gestures that actually works
It can be done. Quite a few laptops are now getting there.
What I wanted was a damn trackpad that was awesome. I spent a lot of time in different stores trying various laptops and their trackpad. Nothing came close. So I ended up with an Macbook. All in all they are solid workhorses that take a lot of abuse. The biggest gripe is that updates tend to make everything more unstable and my battery life is going to shit with El Capitan.
The way i see it, the return of the Mac has coincided with the rise of the Web. This because the web started as a document layout format, and thus formal courses found themselves in the same group as "media production" (print media in particular).
And that world has been a Mac bastion since the earliest day of gray scale screens and Photoshop 1.0.