Ask HN: How does a 1990s web developer get back on track? - <AUTHOR> During the late nineties I was making various interactive/dynamic websites using the then standard technologies: HTML, PHP, Perl, Mysql, and a tiny bit of CSS. This was the time when Javascript was really only used for form field validation and to spawn popups (Ajax was not yet around), when all layout was done using borderless table/tr/td HTML elements, when there were no mobile devices and all you had to care about was one or two screen resolutions and basically two browsers: Netscape and MSIE. Since then I have been pursuing my IT career in a different area. But sometimes I still find myself wanting to setup a website every now and then. But in the little free time I have available, I stumble upon all kinds of web technologies and frameworks: JQuery, Node.js, Ruby on rails, AngularJS, Backbone.JS, Django, Bootstrap, to name a few. Ofcourse all have their purpose, weaknesses and strengths. But after work and family, there isn't much time left for exploring and trying new things. Maybe other people have already made this journey and can share their experiences? What would be the best way for a nineties web developer to update his knowledge and skills? <comment><USER2> My take is that a greater percentage of websites can be written in HTML and CSS than currently are: both in the sense of websites that could be entirely written in HTML and CSS and as portions of websites that can be written in HTML and CSS instead of with something else.

Many of current batch of tools were developed to meet the needs of engineering teams at scale: e.g. Angular @ Google and React @ Facebook. Their heritage is not "hobbyist programmer" friendly. They are great if the hobby is reading about technology. But many many of those opinions embedded in Django and Rails only become natural once a person is deeply familiar with the culture of their communities.

My advice, do the simplest thing that will work and make something. Pick tools that require a lower level of commitment to an overall architecture as the need arises. Stay out of silos and rabbit holes.

Good luck.

<comment><USER3> Completely this.

If I teleported here from the 90s, first thing I'd need to wrap my head around is how HTML and CSS have changed. I'd be learning a responsive framework (or even hand-rolling it, so you _know_ how it works) like bootstrap. And doing a very basic website.

And if html5 & responsive css aren't enough to wrap your head around at once, I'd create a github account, and start with github pages. That'll let you use the static site generator Jekyll. The combination of all three will do pretty much all you need for 90% of the sites out there.

After that, then I'd look at a stack that lets you have some degree of interactivity and persistence in order to build web apps.... But for now, clean responsive websites would be the way forward.

<comment><USER4> Take a look at Susy for layout, bit more flexible than Bootstrap:

[https://github.com/oddbird/susy](https://github.com/oddbird/susy)

Also for static site generators take a look at:

[https://middlemanapp.com/](https://middlemanapp.com/) (Ruby) [http://gohugo.io/](http://gohugo.io/) (Go) [https://github.com/getpelican/pelican](https://github.com/getpelican/pelican) (Python)

When you need to go beyond static sites and take a look at the web frameworks - Ruby on Rails is the obvious one, but I reckon that Meteor ([https://www.meteor.com/](https://www.meteor.com/)) could be a good bet now that it has matured. Might save you a lot of time when compared to RoR for certain tasks.

<comment><USER5> Imo I'd hold off on susy. Bootstrap is a great start for a beginner abs it's used in a ton of environments.

<comment><USER6> I took several years away from the front-end to focus on Backend and DevOps, only recently re-upping my front-end-fu. Since I knew CSS 2.0, I found Bootstrap quite easy to pick up and be productive with in about a day, not previously knowing CSS griding. And I found myself saying over again, holy shit where was this back in "my day"!

</comment></comment></comment></comment></comment><comment><USER7> Here's a semi-controversial opinion: you probably don't need to learn much.

You don't need hipster.js to build a website. You can still build websites that can be used by millions of people using PHP, mysql, and HTML.

Lots and lots of people will tell you to learn hipster.js, and will imply that if you aren't using something written by 3 20 year olds in a coffee shop during a hackathon, that you can't get The Scale.

But the reality is that people have been getting The Scale with the tools that you already know since you learned them.

Here is a relevant blog post: [http://thingist.com/t/item/21434/](http://thingist.com/t/item/21434/)

<comment><USER8> This isn't a very controversial opinion on HN. It's the standard "js developers are just crazy ADHD kids and all they do is chase the latest shiny framework every week". It gets featured prominently in every thread that mentions webdev.

It's also wrong. There is a spectrum from early adopter to head-buried-in-the- sand cobol developer, and most people would agree there are trade-offs to being on either end.

Suggesting to someone who has been out of the game for 15 years that basically nothing has changed is doing him a disservice and not answering the question. He's asking about what he's missing, it's better to let him in on it and let him decide for himself if it's really just the same old shit repackaged.

<comment><USER9> On that note, I'd throw in SPA's and REST. Thats a big conceptual difference in how apps are built nowadays and worth to get up to speed with.

</comment></comment></comment><comment><USER10> Wow, there is a lot of awful advice in this thread.

HTML, Javascript and CSS are still extremely important and they have come a long way since 1990. Forget everything you knew about them and research their state in 2016. You have a lot to learn, but you'll find all three more powerful and expressive today than they were in 1990.

There is currently a big shift in the way clients want their websites to work. In the past (and present) clients were happy with simple HTML pages that were generated on the server and sent down to the client for every action the user performs. Now and in the future, we're shifting towards "Single page apps" which are Javascript centric applications that store page templates client- side and talk to the back end through APIs. Page transitions are emulated with Javascript routing libraries. This means the frontends are more complex but can provide a richer, more interactive experience. To see the cutting edge of this technique search for React + Redux.

Backend development is still important. People generally converge under a simple set of rules for backend development called Model-View-Controller. This is a design pattern that dictates how requests are delegated into your business layer. Investigate MVC as well as Domain Driven Design to get yourself up to speed.

Understand that there is an enormous amount of garbage out there right now. Some things to be extremely wary of are NoSQL databases (they have very limited use cases but are marketed as a silver bullet) and NodeJs (a backend server which executes Javascript but has more than a few shortcomings). Be extremely skeptical of any advice you receive over the internet. There are too many people dispensing advice with no actual credibility because of the ease of access to the Internet.

The best thing to do is to work with some talented developers and build your own network from them. A lot of developers on the leading edge use Twitter and often drop useful bits of advice to keep you on the right track.

<comment><USER11> But users hate them. Users want their browser's back button to work in a sensible way.

<comment><USER12> So true. But people who pay web designers like them.

</comment></comment></comment><comment><USER13> Asking here probably isn't the best thing, because most people here are at the forefront of the latest and greatest, so you will probably get a ton of suggestions and reasons why. Throw mine on top of the pile as well.

You need to first define what your goal is. Do you want to become a full-time front-end developer? Do you want to be a full-stack, etc. Different aspects will require a different subset.

First and foremost, you will need to figure out how to get more free-time so that you can master a whole slew of technologies that have come and gone in the last 20 years. This is a cold, hard fact. You have a lot of ground to make up for, and if you can't even start up a web site, it's going to be tough getting legitimacy as a modern front-end developer.

I would start off with the fundamentals, ie. HTML, CSS, and Javascript. Knowing how to build things from scratch, using AJAX, etc, from pure Javascript without frameworks will help you understand why some frameworks are better than others. Then you can migrate to JQuery and Bootstrap. Once you have mastered these, you can then go on to whatever current framework best suits you, but you'll be able to understand the current challenges best.

<comment><USER14> Thats interesting. Are most people on HN web developers? It makes sense I guess. Im an old C++ programmer and I get the vague feeling that I'm in a minority here. Has there been any polls on HN demographics? Who are you guys?

<comment><USER15> I'm a desktop applications dev working for an engineering consultancy. I mostly develop and maintain our GIS and simulation applications.

We use a combination of C++ and Java with an Oracle PL/SQL back end.

We plan to deliver some of our applications through web applications/services over the next few years. I've touched on Javascript a bit but as of this moment, I have very very limited exposure to web development of any kind.

I've only been programming for just over three years though, so I'm still kind of in my junior stage.

<comment><USER16> Do you sometimes feel left out or that you may be limiting your future career prospects? I am a Java application developer with also limited exposure to web development and it is difficult to not feel disconcerted with all the JavaScript talk.

I've started tinkering around with NodeJS but I'd hate for it to get lambasted just as soon as I've mastered it. The frameworks and tools in web development feel transient to me, and I'd hate to build my career on a foundation made of sand.

<comment><USER15> > Do you sometimes feel left out or that you may be limiting your future > career prospects?

Sorry for the late reply.

I definitely feel like the longer I remain with my current employer the more I'll stagnate and the less employable I'll be over time.

We have plans here to start offering some of our applications through web services/web applications but realistically we won't even hit the implementation stage for another three or four years. SO as of now, most of the developers here basically only have raw desktop development experience.

This is the reason I am currently looking for a new job. I have a couple of interviews lined (also turned a few interviews down due to distance from my home) up and the main concern with most of the telephone interviewers has been my lack of exposure to web technologies. Most are understanding enough though to see that an 'easing in' period would be required for me to start working with Javascript and RESTful services etc. It may also help that I haven't been programming professionally for very long.

I should say though that these positions I have interviewed/am interviewing for are back-end Java/C++ positions with companies that offer their products and services through web and mobile applications and not purely web developer posititions, so I would still be working mostly with either Java or C++ technologies and frameworks, just with an eye towards web and mobile delivery.

I don't particularly want to be purely a 'web developer' anyway, but i do want to learn more about web technologies, and I want to learn it as soon as possible.

As it stands now I am considering learning (in my own time) more about Javascript and associated frameworks so I can understand more about web development in general. I have the same concerns as you though, things seem to move so quickly in that arena, frameworks seem to fall in and out of fashion in the course of months or even weeks and I am having trouble knowing where to start.

It also doesn't help that I'm trying to (slowly) learn to the Android 6 SDK at home with an intention to try to pick up the Rust language as well. I'm clearly trying to take too much on.

<comment><USER16> No worries, thanks for responding. I'm in a pretty similar position to you although I haven't yet reached the 3 year mark, more like 2. I also tend to have ADHD with my hobby projects that I do on the side. There's this open source project based on Rust that I want to contribute to on my spare time (I've already looked at Android and made an app, but for some reason I'm not compelled to pursue mobile development professionally) and of course I've already told you about NodeJS.

Easier said than done, but I'd advise to just stick with the web dev right now and focus on the other stuff later (if ever). Web apps are increasingly standing in for native mobile apps (that's partly why I gave up on Android) and Rust hasn't really reached a level where it's lucrative for professionals. Just be pragmatic and catch up on your web stuff right now (like I am right now) and once you think you've covered your bases then you can focus on the "for fun" stuff (Rust - although it would be awesome if someone could prove me wrong).

<comment><USER15> I can see what you mean with regards to mobile development. Android is not exactly 'fun' to work with so far.

So much XML, it feels like you need to write two or three times as much code to implement any functionality than you do on any other language/platform. It feels so heavyweight.

I think you're right though, I might delay picking up Rust for a while and learn some web tech. It was just going to be something fun to do in my spare time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> > _But in the little free time I have available_

> _But after work and family, there isn 't much time left _

If you want to ship ASAP with little time investment, IMO nothing beats Meteor. Skills required: HTML, CSS, JS.

I've built projects with PHP, Rails, Django, Node, Angular, etc ... and Meteor is the framework I recommend to newcomers. Ok, you're not exactly a newcomer, but clearly you've been disconnected many years and you don't have enough free time to learn new tools/languages. You'll need a lot of abstractions (features, deployment, db interfacing, best practices, etc)...

Meteor will help you with this, a lot... And the most important thing: it's a lot of fun!

[https://www.meteor.com/](https://www.meteor.com/)

0,02

<comment><USER18> +1 for meteor highly recommend to start with [https://www.discovermeteor.com/](https://www.discovermeteor.com/)

<comment><USER19> No, discover Meteor is extremely outdated.

<comment><USER20> I wouldn't say it's "extremely" outdated. The info inside is still valid, you can start with it and then complete your knowledge with the Meteor Guide.

</comment></comment></comment></comment><comment><USER21> It's pretty easy to break it down to the common parts but there definitely is quite a bit to learn.

NodeJS or Python or Ruby

These are your fairly standard backend choices. They all have minimalist and full featured frameworks for building applications including but not limited to Express, Koa, Ruby On Rails, Sinatra, Django, Flask. Go is also fairly easy to get going quickly in. There is not really a wrong choice here for a personal project.

In the case that you want a single page application that works with the backend you made with the previous choices:

Backbone or Angular or React+Redux(any flux implementation will do)

These are for consuming your backend and any of them will do. Learning Angular is its own thing despite it being javascript. React+Redux seems a little odd by embedding html in your javascript but once you get the hang of it it's pretty neat. Don't know much about Backbone but I've heard its fairly easy to use.

Bootstrap is pretty easy to learn and use to make your website responsive with minimal effort.

Heroku is by far the easiest platform for deployment and horizontal scaling however it can get pricey quickly. AWS has a similar solution with Elastic Beanstalk but I've got no experience to share with that. If you want all the control (but more work) you can go with Digital Ocean for a 5$ VPS. Unlike Heroku you will have do all admin work like installing necessary packages, databases, and configuring a web-server but you can control every little bit of your application without having to spend more than $5 a month.

</comment><comment><USER22> As a former Java/Spring developer from the mid-2000s trying to get back into the fold, I think Ruby on Rails is the best bet. It is not the latest and greatest and its a tad slow performance wise but what it lacks in speed it makes up in clarity. Especially on the documentation/tutorial front which makes for a quicker learning experience. I find the most interesting part of RoR is its "curated" (almost Microsoft like) environment where choices are mostly made for you instead of banging your head against the wall making choices about all the different libraries and tools you should use.

<comment><USER23> +1 to this

<comment><USER24> (can we post meta things?)

Given that I don't know the score of the answers, such "+1" answers are useful to me. Thanks!

</comment></comment></comment><comment><USER25> Instead of trying to do it all at once you might want to take it in chunks.

I would start on the front end and

I would start with looking into Bootstrap and jquery. And look at using PHP to deliver the webservice data to jquery. [http://tutorialzine.com/2015/01/shoutbox-php- jquery/](http://tutorialzine.com/2015/01/shoutbox-php-jquery/)

\</comment><comment>

I would also google some MVC PHP tutorals to get some idea of how MVC works since alot of modern frameworks are modeled after it.

\----

next pick a javascript framework to make a SPA here's some tutorials(middle of the page) on using angularjs with php: [http://www.angularcode.com/](http://www.angularcode.com/)

\</comment><comment>-----

now your ready to swap out php for another server technology. nodejs, RoR, whatever.

\</comment><comment></comment><comment></comment><comment>---

<comment><USER26> +1 for just starting with bootstrap - which will introduce you to a little jQuery. That'll be a good foundation and will allow you to have some fun without being overwhelmed.

Once you have that in your pocket you'll be ready to try any of the new js frameworks that are being mentioned here.

</comment></comment><comment><USER27> I'll chip in as a recent animator-turned-web-developer:

1\. Learn plain old JavaScript([https://developer.mozilla.org/en- US/docs/Web/JavaScript](https://developer.mozilla.org/en- US/docs/Web/JavaScript)), paying particular attention to both ES5 _and_ ES6. Most of the latest frameworks work with JS as its base, so if you know JS you'll likely find it easier to figure them out.

2\. Learn CSS(it's easy, shouldn't take you more than a couple of hours) and then dive into SASS or LESS.

3\. Take some time to learn how Node and it's package manager npm work.

4\. For the more back-endish choices, I'd have a look at getting a basic understanding of NodeJS, RoR and Django. One of these should appeal to you more than the others and I'd just pick one and stick to it.

<comment><USER28> `Learn CSS(it's easy, shouldn't take you more than a couple of hours)`

That's kind of hilarious.

</comment></comment><comment><USER29> Keep doing what you're doing with the frontend. (Although you're free to use modern backends.) The web today is a horrible mess of slow garbage expanding around the content that matters. Forms should POST directly to a URL when submitted, all content should be generated by the backend and served upon a GET request. Javascript should be used for form validation, interactive elements like OpenStreetMaps, but nothing else. Modern CSS is great, but designers abuse heavy features when they lose track of the purpose of a website: to serve content to your eyes and to allow the user to navigate with hyperlinks.

<comment><USER10> "Javascript should be used for form validation, interactive elements like OpenStreetMaps, but nothing else"

Not if you want to get hired. We've moved on from that simple model. I don't like it either but ignoring the fact that things are changing is a good way to end up unemployed.

<comment><USER29> That's true I suppose, since I develop primarily for fun. But promoting this minimal/ideal state of web development can only improve the experience of users. The excitement of using bloated web frameworks might help your startup, but when it seeps into well-designed free software made by the consumer for the consumer, it hurts the product.

</comment></comment></comment><comment><USER30> Two paths you might consider:

1) Focus on HTML/CSS and use a static site solution (github pages + jekyll is hard to beat). When you need more, learn the JS necessary to make it happen, and perhaps move beyond static and into more JS-front-end territory as needed.

2) Tap into your PHP memories and take a look at Laravel and specifically laracasts.com. I'm not proselytizing (I actually don't use php or Laravel), but it's a really solid framework with a vibrant and heterogenous community. It may not where the cool kids are, but it's a great way to be productive and it seems to be constantly improving.

Good luck!

</comment><comment><USER31> First, don't worry about new frameworks or languages right away. You can stick with PHP/mySQL on the back end to start.

Learn all the updates to CSS first, to understand how pages are structured without tables. That will help you to move on to jQuery, which will in turn help you understand how JavaScript is used nowadays to work with the page. Once you are that far, you can pursue node.js to get up to speed on server- side JS.

After that, you should be as caught up as you need to be, and will better be able to evaluate all the other frameworks and languages out there, and set your own direction.

</comment><comment><USER32> Get up an hour earlier than you do each day. It's hard when you start, but if you don't have much spare time then it is the best way to keep up with the industry.

Spend this time updating your knowledge base via. tech news, tutorial/e-course sites such as Udemy/Pluralsight (if you learn best by video-and-code) or official textual documentation/guides otherwise.

Learn about version control (Git), HTML5/CSS3, ECMAscript 6... PHP and MySQL are still fine. Read guides about modern practices such as mobile-first development, testing via. Chrome developer tools, file minification/concatenation etc. Just learn a little each morning and don't feel overwhelmed!

Consider the points of the following link and don't worry about the "flavour of the week" libraries so much and you'll be fine -> [http://programmers.stackexchange.com/a/46760/74224](http://programmers.stackexchange.com/a/46760/74224)

</comment><comment><USER33> Find a problem that is not easily solved by your current knowledge/experience and explore it. Having a clear goal does wonders to provide focus and limit the chances of being overwhelmed by "all the things."

When you address the problem, don't immediately jump to the newest framework/stack that claims to solve it but instead try and use the majority of your existing skills and knowledge with one or two modifications... even if they are "out of date." Going through the effort of adapting existing skills allows you to better understand the underlying problems as well as re-live (in blessedly compressed time) the iterations that occurred to arrive at the current accepted solutions. There's a lot of wisdom to be found in taking that journey.

Learning the "why" of things is far more important than just acquiring the operational skills for a given technology.

</comment><comment><USER34> CSS3 & jQuery. That's it.

HTML, PHP & Mysql are all still quite very relevant.

Replace: [table/tr/td] with [div/ul/li] and substitute the borderless tables with the CSS3 box model and you're _TOTALLY_ up-to-date. No lie.

Right-click > Inspect Element > Console > console.log will get you a long way. Treat the JS console as your new client-side command line. Just start typing in function names, and see what autocompletes. Treat JavaScript functions as if they were executable binaries within a shell window. Use jQuery to traverse the DOM with CSS selectors. This behavior is well-supported in pretty much every current, modern desktop browser.

Everything else is quite honestly a fad, and replete with over-engineering pissing contests. I'd add more opinionated snark to this last part, but that would dilute the important parts of this comment, which I do hope reach you well.

<comment><USER35> I'd like to highlight that Wonka has it right (CSS3 & jQuery) and also add that NodeJS is pretty important right now for server-side.

The reasoning here is that the heart of the web is, and has always been, HTML, CSS, JS.

jQuery is a natural choice because it's replaced direct DOM manipulation quite elegantly and is used by 80% of websites. The only thing you're missing is server-side, and Node makes this an easy choice by also being JavaScript.

In short, it's all about JavaScript. If you can code, you'll do well. Keep practicing functions and with Node you can practice command-line apps, or server-side apps as well. Good luck!

</comment></comment><comment><USER36> Check out meteorjs. Javascript has a huge amount of buzz and usage these days, and meteorjs is a fairly simple fully integrated environment that allows you to do just about anything. I don't use it - I have been developing software since the early 90s and I am currently working in RoR. But when I want to play around, it's in meteorjs. In my opinion, too many teams are using an environment that is too complex, ensuring that nothing is predictable.

<comment><USER37> Although I do like Meteor, I don't think it's the right choice for the OP. Surely Meteor is easy to grasp, but its fundamentals rely on many technologies (React/Blaze, MongoDB, NodeJS) that a out-of-practice developer may struggle a little.

That being said, I'd recommend the OP to dive into modern CSS frameworks (Bootstrap, Semantic UI, Materialize, to name a few) and learn more JavaScript. After that he will probably feel what he likes/dislikes more and find the most suitable framework for his needs.

</comment></comment><comment><USER38> I don't know what any of those things you named are. I ignore all that stuff. The only thing from the '90s that doesn't work anymore is Flash, because I guess Apple blocked it during the mobile revolution and it killed its dominant position.

Otherwise, everything applicable from back then still is today. Any time anyone mentions PHP on forums like this, there's always fashion-conscious people who jump in to attack it. But I'm still building brand new websites based on it, and people still express their gratitude, never once saying there's any problem because the site uses PHP.

MySQL is still going strong, and there's some alternatives that are compatible, like Percona and Maria.

JavaScript is the same. There's all these frameworks like there are for PHP, but I ignore all that. I never understood why I'd be better off using someone else's virtual language on top of a language. I just use bare JavaScript, and it works the same to me as it did back then. Still have to worry about differences between browsers, but instead of Netscape and IE, it's stuff like Chrome, Firefox, and Edge. A framework can make that easier, but it can make others things more difficult, and it's better to keep dependence on JS minimal anyways.

What I'm getting at is, I don't know why you need to update anything. If you're trying to get a specific job, then you need to use what they do. But for just building things in your free time that work on modern web browsers, you already know what you need to know. You could probably even run the same exact version of server and authoring tools you did before, and it should display fine in the latest web browsers.

It's different if you want to build something like a mobile app, or Windows software, because those platforms changed significantly since the '90s. There's languages now that didn't exist then, and new tools you've never seen before.

But on the web, any text editor, HTML, and any language you want for the backend is fine. Just like I still write .sh scripts, and they get the job done.

It's more important to spend that time on family, and your career. Since the stuff you already know still works, there's not much need to use anything else. Unless you're worried about what the kids think, and how they'll judge you.

<comment><USER10> "JavaScript is the same"

"What I'm getting at is, I don't know why you need to update anything"

Shocking advice. There is a huge amount to learn. Any developer coming from the 1990s needs to re-learn all their technologies or they are going to have a very stressful time delivering anything appealing to users expectations in 2016.

"Since the stuff you already know still works, there's not much need to use anything else"

This kind of mentality leads to becoming deadwood and unemployment. Developers must keep learning especially with the rate of change of technology over the past 5 or so years.

<comment><USER38> I don't think most people creating websites today have an accurate assessment of "user expectations". Often I'll visit a site that has a gigantic video playing, with some obscure symbols, that doesn't even work on all my devices. Or if I have JS turned off, a blank page.

I'm building things the same way as I did at around 2000, and my creations are just as relevant today. Most of the fancy JS stuff we could do in the '90s. The new stuff is not about basic websites, but how some new additions of HTML5 work. Most websites do not need those though, and if they do, then you learn those specific things.

</comment></comment></comment><comment><USER39> You've answered your own question: there's no _need_ , you have no _problem to solve_ by writing an app. Usually the problem itself dictates half the technology choices for you, and the rest are filled in by using what you already know. In your case though, you have no _reason_ to write an app. So the only answer that makes sense is "none".

</comment><comment><USER40> You could start slowly teaching yourself more about new technologies, but try and become even more an expert on the stuff you already know.

Perl and MySQL are strong choices and there must be a lot of big companies out there who still use them because it works for them. Startups always want the cutting-edge technology (NoSQL), but sometimes a good old RDBMS like MySQL is the way to go.

Inspired by: [https://news.ycombinator.com/item?id=10084449](https://news.ycombinator.com/item?id=10084449)

</comment><comment><USER41> Since you've done PHP and MySQL previously, if you still remember how to use that, it's worth starting with a simple PHP micro framework (like Slim, or maybe Symfony 3). That will teach you about using URLs for routing. (If starting from scratch, pick a language, and pick a micro framework for it: Ruby => Sinatra, Python => Flask)

Get comfortable with that, and then create a route that sends back information in JSON instead of HTML. That will then give you something to try Ajax against.

Also, learn CSS. The Web switched to CSS for layout in 2001-2004. Have a read through 24ways.org -- their advent calendar for each year, it's nice bit size bits about modern web development. CSS for layout. Responsive design (basically adapting to various browser window sizes and screen resolutions). If you want to learn how to lay out a page in CSS this is essential, but if you want to get up to speed just building stuff, then taking something like Twitter's Bootstrap is a handy starting point.

Also, jQuery. Learn about using events properly, and keeping JavaScript in a separate file and hooking into the browser/document events you are interested in. jQuery is the starting point for getting your head around Unobtrusive JavaScript.

If you are interested in getting your head around static HTML/CSS sites first, it might be worth pulling up a Jekyll tutorial and following that. (Jekyll is a static site generator. Markdown documents rendered as static HTML using the Liquid tempting language)

</comment><comment><USER42> "Frameworks" are definitely the word to describe what has changed since you left us and you've certainly mentioned a few, but the way websites are pieced together is _largely_ the same. A bit of dynamic code sharts out some HTML and that gets rendered with some CSS (and occasionally some JS).

I'd leave the backend stuff well alone to start if I were you. If the last browsers you were testing against were really Netscape and IE4, I'd strongly suggest you start with the design side of things. Bootstrap is a great framework for writing little CSS and reaping a many-device-compatible site. There are alternatives like Materialize.

So build a one-page static website and see how that all fits together. Change the design. Consider digging into the CSS (or LESS/SASS CSS-generator languages). You can do a lot with static sites. There are even form-handling third parties to take out the hard stuff.

Once you're on top of that, you're in a good spot to go dynamic; learn database modelling, templating, URL dispatchers and all the jazz that is specific to the backend framework of your choice.

Don't feel pressurised to stay with PHP. You haven't used it in years and I'd argue it's everybody's favourite punch-bag for a reason. The quality of tutorials is much better these days so picking up something like Django or Rails without prior Python or Ruby experience is easy. But don't try to master them all at once.

The best way to learn is to dig in and build.

</comment><comment><USER43> It looks like you have a good background on things. As a polyglot with experience in plenty of languages, I'd minimize the number of syntaxes to pick up. I would focus on leveraging your javascript background as a starting point.

Let me tell you why.

Not much has changed since the 90's in one area: there are as many opinions and interpretations running around as facts. There's no shortage of time being spent re-inventing the wheel over and over in frameworks that really don't look much different. The end result is most languages have pretty decent frameworks to work with.

A better question is what would be a best path forward for you to dip your feet in and move forward?

The web and mobile landscape is a lot nicer now with the tools that aim to help you get things done quicker, as long as you don't go off their beaten path.

Which two swiss army knife tools could you use to roll out into one thing?

The first big shift is to think mobile first, including mobile web based apps that also work on desktop.

I've jumped into Javascript more so in the past year as node.js has continued to mature. I use my strategically limited time to build value and not spend my time learning like I had to in my 20's.

The frameworks I'm playing with at the moment that provided a good coverage for web applications as well as doing mobile web app dev, as well as mobile app development.

Sails.js (forked to trails.js now) will be familiar to you. This will cover writing web apps and not having to build your own entire stack. Has worked wonderfully for the few projects I've used it for.

To cover mobile development, I recommend looking at ionic framework to start out with. It can connect just fine to a backend like parse.com.

There are no shortage of business and information driven apps (that pay well) that this technology can create with one code base for all end points. There is a great case to build native apps once something like this solves a problem.

If you want to get into mobile development from a higher level to explore, I really recommend a tool like appery.io. It was dicey before in places but now has ionic built in, it's a fantastic prototyping tool for JS apps.

Beyond this, I've always had a crush on Python and want to spend more time with it, but for now Javascript keeps me moving along.

Feel free to reach out if you wanna chat, you sound like you have a lot of experience already.

</comment><comment><USER44> Same here. I used to make websites around late nineties and early 00s (I was about 12-14 at the time, but was doing a surprisingly good job), but find myself a little bit lost now. So, while I'm certainly not a professional web developer now, here's what I found useful in my small hobby projects.

First of all, I'm not trying to best solution — I'm pretty satisfied if my solution is just good enough. So, instead of top-notch technical quality, I aim for easy to learn tech, because I don't have a lot of time. So, I ended up using Angular in a couple of places for the client-only web apps, and using server-rendered templates backed up by Django on others. Both are mature frameworks, and both have a lot of very valid criticisms addressed at them — by professional developers that create huge projects at scale. Which I'm not, so I don't really care. And in terms of working with HTML, I always end up using Twitter bootstrap, which offers a reasonable amount of template elements that don't look ugly.

I also tried to use different project management/automation tools like npm, grunt, bower and else — because in my main line of work I can't live without em. However, I ended up that I have to spend too much time learning them compared with how much of my time do they save. So, now, instead of proper package management, I just copy minified sources and write a couple of makefiles and bash scripts to automate stuff instead of using JS and Web- specific tools and their special formats.

All of this was really hard for me, because I always feel an itch when I do not automate something that should be automated, copy code or in general, don't dig enough to find the best practice possible. But in this particular case, because I only create sites for small hobby projects, I had to make myself give a little bit less fucks, and spend this time working on actual functionality instead.

</comment><comment><USER45> Being that you are already familiar with HTML/CSS and PHP, I suggest getting updated with those first. Learn responsive design or Bootstrap to get started on the front-end (HTML). Do some reading on the latest CSS best practices and go through a couple of JavaScript and jQuery tutorials. For PHP, I suggest reading through [http://www.phptherightway.com/](http://www.phptherightway.com/) because a lot has changed with PHP over the last few years.

All of this will give you what you need to built out a robust site. After you are updated and comfortable with these, you may then decide to move onto learning other things such as React, Node, etc.

</comment><comment><USER46> Prefacing this with "I'm in my 20s and don't know what development was really like in the 90s", but I want to suggest an alternative approach...

It _looks_ like the thing that has changed most is not the languages and frameworks (you can still use PHP, MySQL, effectively), but actually the deployment.

Automated deployment, continuous integration and delivery, and cloud services like AWS seem to be the bit that has changed the most.

If I'm wrong, ignore me, but otherwise, I'd have a play around with something like Ansible, use a few AWS services, some of the more value-add ones (i.e. not EC2 or S3) to see what you can now get "off the shelf".

</comment><comment><USER47> I was taught table layout in school and had to relearn everything. First place I'd start today is [http://diveintohtml5.info/](http://diveintohtml5.info/). After that look into CSS3, [http://myth.io](http://myth.io) helps you make sure your styles are cross-browser. Lots of comments talk about static generators and web frameworks already. Use the JavaScript pixie dust sparingly and you'll be fine.

</comment><comment><USER48> HTML5. Read Mark Pilgrim's _Dive Into HTML5_. And by read, I mean, both the material, _and_ view-source and his stylesheets. The site itself is a tour de force of what he describes.

CSS2 and CSS3. The latter is where CSS headed, though it's still in development.

You can do a hell of a lot of sensible page design with just straight HTML5 and some modest amounts of CSS.

Javascript for any automation.

CodePen is a great place to play with (and explore for) ideas. StackExchange and Reddit's /r/WebDev and other subs for Q&A with other developers.

Maciej Cegłowski's rants on current Web faults / advertising / privacy [http://idlewords.com/](http://idlewords.com/)

There are others who hit this point, and do it well, but Maciej makes a compelling case on all three points (with essays featured here on Hacker News). My read is that the Web is headed for a crisis on the point of design, on many grounds (readability, privacy, annoyances, accessibility), and that, despite much of what I've written above, read Web design may well die. With "Reader Mode" features being included in more browsers these days (Safari, Firefox, Chrome is coming up with it, Opera's had it, not sure about MSIE), readers can simply opt out of design. Which may be a Good Thing.

Enjoy.

</comment><comment><USER49> It depends on what you want to do. If you want to get a pro job then it takes a lot more time investment then a hobby.

I started out in the same tech stack and have been doing this since late 2000s. TBH, a modern web framework with a js frontend is overkill for a hobby project. If you want to mess around with just the front end, start with a hackable static site generator like [http://spress.yosymfony.com/](http://spress.yosymfony.com/) Hack the templates and you can get a good starting place for how much has changed on the front end.

Learning WordPress templating is another good hobby kind of place to start. Actually, if you get really good with that, you can probably turn it into a job on its own (though less money than more full stack type work).

If you were wanting a career change, you need to learn just enough of one backend framework and just enough from a frontend framework to land an entry job. Then learn everything you can from reading someone else's code. There is no project that you can do on your own that would teach you the entire stack as quickly and you'd get paid to learn it.

</comment><comment><USER50> I agree with the opinion of many others in this thread that you'll be able to recycle a good amount of your skills, but you may want to get familiar with a couple additional tools;

1\. Start by creating a GitHub [1] account if you can.

2\. Get started with a simple GitHub page. This will get you familiar with the GitHub interface, some basic Git concepts and will refresh your HTML skills.

3\. Hack around the CSS and templates. Have some fun an break things.

From there you can start exploring more things;

\- Start looking into SASS [2], which is natively supported by Jekyll [3].

\- Set up Jekyll on your local machine [4] (beware, I've always found Ruby to be a mess to deal with).

\- Add jQuery [5] and start adding some simple effects (scroll to the top, maybe look into adding simple toggle effects for menu on mobile).

Now, you could go and try to learn more advanced stuff (React, AngularJS and all that jazz), but with a GitHub account and some knowledge of HTML5, CSS3 and JS/jQuery you'll be able to do a fair amount of damage already. Worry about the fancy stuff later on once you're comfortable again with building sites.

PS: don't use tables for your layouts, and don't use Dreamweaver ;). Atom [6] is a good free alternative editor from GitHub. You can figure out later on what works better for you (Sublime? Eclipse?) but it will get you started.

Also, Codecademy [7] is your friend.

[1] [https://pages.github.com/](https://pages.github.com/)

[2] [http://sass-lang.com/](http://sass-lang.com/)

[3] [http://jekyllrb.com/docs/assets/](http://jekyllrb.com/docs/assets/)

[4] [http://jekyllrb.com/](http://jekyllrb.com/)

[5] [https://jquery.com/](https://jquery.com/)

[6] [https://atom.io/](https://atom.io/)

[7] [https://www.codecademy.com/](https://www.codecademy.com/)

</comment><comment><USER51> Well, let me jump in here too. Just relearn HTML, JavaScript, and CSS = HTML5. I therefore recommend two books:

JavaScript for Web Developers and CSS3 The Missing Manual. Don't overthink this. From this you can move on to frameworks if you feel you need them.

Now, concerning the backend ... well, lots of choices. C# with ASP MVC, Ruby, JavaScript with NodeJS, PHP is still very relevant. Pick what you like, seriously.

</comment><comment><USER52> It depends what you are trying to achieve, but acquiring a cms of some variety, then hacking on that is not a bad way to learn.

I'm not a web UI programmer, although have been at times over the years and still do some professional work in that space, but a little while ago I created a website for a friend's business as a hobby project for me.

I chose to use Drupal, which is a php based cms, and used a paas called pantheon. [https://pantheon.io/docs/articles/getting- started/](https://pantheon.io/docs/articles/getting-started/)

The good thing about this approach was that I had a fully functional site to start with, built with reasonably good practices (progressive enhancement etc), and I was able to hack away on it and taught myself some php as I needed to achieve certain things that weren't available out of the box. I found it quite interesting to dig around and see how they structured the site, particularly the css strategies.

</comment><comment><USER53> I'm a sales guy first and foremost, and develop for fun on evenings and weekends when I have some spare time after my child had gone to bed. 90% for fun, 10% for a small side income.

For what it is worth I taught myself Ruby on Rails and MySQL, however in hindsight I probably should have learned php / MySQL as it seems more prevalent, less "hipster.js" and easier to set up basic dev and prod environments.

I still don't fully understand Ajax or JavaScript, however they are "nice to have's" in my book as they improve the UX, but I can still make an application work without them.

An alternative is to learn how to customise a commercial application. Deluge for Zoho is pretty easy (and appears to be based on php), and Shopify's Liquid is good too (that's based on ruby). I found them both easy to learn.

Hope that helps!

</comment><comment><USER54> Seeing as you know PHP try the Laravel framework (disclaimer: I've never used it but have heard that it's very rails like and I use rails daily because it's very fast and easy to get started with). Use bootstrap for your CSS needs (layout etc is too simple to be true and it will save you a ton of time) and once you have the bones of functionality you want start exploring JS tools for adding a slicker user experience.

If you want to look at something new I can highly recommend the Rails Tutorial by Hartl to bring you up to speed on the basics of web dev with rails, bootstrap and ajax. It also teaches you a bit of git which is a must.

[https://www.railstutorial.org/book](https://www.railstutorial.org/book)

</comment><comment><USER55> Luckily, you can skip right ahead to React+Redux. It's really a logical extension of your stack than you think. jQuery and Backbone you can pretty much ignore except know that it's a less elegant and less declarative way to do models, views, and event binding.

<comment><USER56> I've a good few years web programming experience: Rails, PHP, HTML/CSS/JS (jQuery), SQL, ... you get the idea. Apart from keeping up to date with Rails nothing 'modern'.

I've spent the last week (finally!) trying and in the end succeeding to wrap my head around React+Redux. It took a many many many hours of puzzlement. I began with the react+slingshot[0] @coryhouse made as a starter kit and going through the React docs and Redux docs. I guess my desire stemmed from seeing Dan's demo of Redux's time-travel and hot reloading ability, I was intrigued. I copied the TODO example from the Redux docs and fashioned it to my liking exploring all the parts.

I'm here to tell you that it's not easy. The landscape is still in flux (buh- dum-tish, I'll be here all week folks) and that for every piece of the dev tool puzzle you've two or three options.

I think you can get away with React+Redux on the client side which replaces the V in your MVC. {This in practice means the `react', `react-dom', `react- redux', and `redux' files. _Everything_ else is tooling, but my God so much tooling}. YMMV.

That's as far as I'd go, otherwise you're throwing out all your server-side dev experience, and why would you want to do that?

What I'd like to ask folks is: what happens to my nice static HTML/CSS pages if React+Redux is all JS? Server-side rendering? I'll come back and edit this and put in a few more links I found handy. Do believe the hype, React+Redux is pretty neat.

[0] [https://github.com/coryhouse/react- slingshot](https://github.com/coryhouse/react-slingshot) \---

Edit!

React docs: [https://facebook.github.io/react/docs/getting- started.html](https://facebook.github.io/react/docs/getting-started.html)

React DevTools: [https://github.com/facebook/react/wiki/Complementary- Tools](https://github.com/facebook/react/wiki/Complementary-Tools)

The Video: Dan Abramov - Live React: Hot Reloading with Time Travel at react- europe 2015 [https://www.youtube.com/watch?v=xsSnOQynTHs](https://www.youtube.com/watch?v=xsSnOQynTHs)

Redux docs: [http://rackt.org/redux/docs/basics/index.html](http://rackt.org/redux/docs/basics/index.html)

Redux DevTools: [https://github.com/gaearon/redux- devtools/](https://github.com/gaearon/redux-devtools/)

</comment></comment><comment><USER57> After reading the other suggestions, I'm going to suggest static site generators that you can deploy to AWS s3 or Github pages. The most popular of these is Jekyll ([https://github.com/jekyll/jekyll](https://github.com/jekyll/jekyll)) which is written in Ruby, but here is a list of a bunch of others written in many different languages:

[https://github.com/pinceladasdaweb/Static-Site- Generators](https://github.com/pinceladasdaweb/Static-Site-Generators)

</comment><comment><USER58> I pair program with one of my friends for 4 hours one evening a week every single week for the last couple months. I intend to do this forever. We are incredibly productive, pairing forces you to focus, it is an incredible knowledge sharing mechanism, and we are absolutely steamrolling through things we have to learn and yaks we ought to shave. And it's on the calendar, it's repeatable, we never miss even when neither of us really have the energy to work, something about two peoples combined energy gets us in the zone instantly every single time.

</comment><comment><USER59> A lot of the advise here seems to be centered around re-training as a modern web developer -- but what you're asking is "But sometimes I still find myself wanting to setup a website every now and then".

If _that_ (and not retraining for a front-end web development job) is what you want, play with Wordpress. It's mature and in extremely wide use. There are tons of plugins and themes. You'll find the PHP setup familiar, and in my experience, it's more fun to learn by getting 80% for free, and then tune things around the margins.

</comment><comment><USER60> Utilize your strengths (HTML/CSS/PHP/MySQL) they stil are valid and desired.

In case you have lots of time and insist on learning something new.. Since you have no experience in the frameworks you mention, i suggest to not waste time with these "previous" generation of libraries, and instead take a look at (JavaScript) ES6. And subsequently React, which is a nice starting point and in turn requires some considerable JS tooling (node, webpack, babel). But when you're there, it feels like you're 10 years ahead!

</comment><comment><USER61> I don't think you really _have to_ learn a bunch more stuff, but I think it'll be a really nice experience for you to learn a language like Elixir to in the end use Phoenix to set up a web page.

Not because you need it, but because learning Elixir and Erlang with a purpose will give you fresh eyes on development.

I think the above can be said about pretty much any language and their frameworks. Just learn to have learned more and you'll be better for it.

</comment><comment><USER62> JavaScript is king here. You probably know html and css well enough, but as others have mentioned, it has changed a lot and responsive is important.

As for hipster.js, I would focus on understanding how JS acts as the glue for web applications and then adopt a front end framework (eg. Angular, react) and also a back end framework (node.js express, php laravel, etc)

</comment><comment><USER63> Nah, just get a job where you'll have to work with email templates. You will outsmart any html5 kid with your colspans :D

<comment><USER63> (For anyone who doesn't know this: You're still forced to do email templates with tables becaus of Outlook)

<comment> oldo-nicho The last couple of days I've been trying to refine an email template and after many attempts finally started checking out some well designed examples with chrome dev tools and discovered that they were constructed as tables. I changed all my divs to table cells and finally got the thing to work!

</comment></comment></comment><comment><USER64> There's a lot of great advice (and some not-so-good advice) in this thread. I happen to be a '90s web guy who's spent the last six months building and deploying an Ember.js SPA backed by a Sinatra.rb RESTful API. It shouldn't be too hard to find me on Twitter if you want to chat. :-) Best of luck.

</comment><comment><USER65> I think you have to try the tools, build things with them, and see what works. I have my own preferences in terms of tooling, but every option has its adherents, and we're not going to agree which framework is best in this thread.

</comment><comment><USER66> I'd recommend going through some courses like FreeCodeCamp [1] You have courses about Bootstrap, React and much, much more

[1] [http://www.freecodecamp.com/](http://www.freecodecamp.com/)

</comment><comment><USER67> Throw away everything you've learned and start over. Pick something and run with it rather than trying to master everything. Write a simple demo app in a few frameworks, decide what works for you, and just go for it.

</comment><comment><USER68> -I think it is better to advance in the technologies that you know like HTML/CSS and PHP. Advance what I mean is learning about things like

\- First of all don't worry about the new technologies coming out every day. Rather than that give more focus to architecture. learn more about Design patterns, its benefits, its implementation, Code structuring, Optimization, Scalability etc.

\- If you don't know MVC architecture (the most popular architecture) then learn a PHP framework like Laravel or Yii. The framework also teaches you common methodologies like Object-oriented programming, Object-relational mapping, Templating, etc.

\- Once you learned any framework, and, of course, like everyone you try to build an application. Go for it. But at this type when you deal with HTML try to improve it slowly. Like learning more about tags and setting up the layout. Updating to HTML5 won't be that difficult. It's all matter in practice and you can practice it while building the application. But don't think about CSS until you finish the app.

\- After Building the app then think about CSS. now you spend time learning CSS. Because most of the people think it's a matter of learning the properties and use it. To some extent it's true, but when you deal with real scenarios it's not. A simple CSS issue can bring down the business for an hour. It's very critical. So give a bit time in learning CSS and CSS3. When you learning, understand more about Organizing, Layouts & Web Typography. The terms sound pretty big. But it's very easy to make it as a practice.

\- Once you understand CSS, add that knowledge to the app you are building. But before that, I suggest you make a pencil and paper sketch of the page and components. You can search for grid paper (with browser template) download and print it. And use that for drawing, because it helps to calculate the pixel values. and it helps you writing CSS. The sketch acts as a blueprint for the CSS. and Its fun doing. you feel like an engineer.. :)

\- After all, if you are still thirsty then learn jquery. after that, Javascript design patterns and then after any frameworks like ReactJS or AngularJs or etc.

\- Learning a PHP frameworks help you a lot in learning HTML, CSS, and basic javascript uisng jquery. so its worth trying.

* This is my modified based on my real experience. Long ago I started from system maintenance to a Geographical information system engineer to a backend developer to a frontend developer and now to a designer. and I also travel through the same path you travelled PHP, HTML and CSS. and little bit python. This is just a vague suggestion. feel free to ask more. All the best

Peace

</comment><comment><USER69> Check to see if your local area has web developer meetups. Then you can observe examples how they create web applications today. These meetups may be under trendy names like "java" and "html5".

</comment><comment><USER70> blhack is right. PHP has undergone a lot of changes since the 90s, but it's still the tops when it comes to open source languages that companies are looking for...at least in Philly. It looked like everything was going to Ruby a few years back, but PHP is holding steady. If you have the time, I'd learn full stack JS - but you can't go wrong with PHP.

</comment><comment><USER71> Would personally recommend you try some modern, beginner-friendly JS frameworks, such as:

RactiveJS - [http://learn.ractivejs.org](http://learn.ractivejs.org)

KnockoutJS - [http://learn.knockoutjs.com](http://learn.knockoutjs.com)

These aren't the hottest or most popular technologies, but they teach good fundementals and are easy to get started with, compared to the powerful but complex frameworks like React and Angular, etc.

</comment><comment><USER72> Basically "Remoting" is now called "Ajax" and front-end developers have build tools now.

</comment><comment><USER73> I would recommend learning steps like this:

\+ Update your php knowledge to modern standards. (i.e. autoloader)

\+ Learn just some sass and use bootstrap 3.

\+ Use something like laravel as a php framework or even smaller like slim

\+ DONT get confused by the plethora of JS-Frameworks. DONT use build tools in the beginning. Plain old <script> tags for the start.

Start building something nice.

sign up on laracast.com ;)

</comment><comment><USER74> I haven't made that journey, and it depends on how complicated the sites you want to "setup" are, but here's my advice as someone doing full stack web development for several years, having started from frameworkless PHP and now preferring the Single Page App (SPA) stack of Flask + SQLAlchemy + flask- restless (REST API framework) + Backbone models + React:

SPAs are only really necessary for certain use-cases, and while having a strict client-server separation does have benefits, it also incurs upfront costs.

You can still get by perfectly well generating HTML server-side with PHP or Perl and MySQL. You may want to check out MariaDB, a fork of MySQL by the original creator if you haven't heard of it. Postgres also finally just added upsert (INSERT ON DUPLICATE ...), which might be the last real barrier to migrating from MySQL, so if you don't have a ton of lingering MySQL-specific knowledge, you might want to start with Postgres, as it seems to be the default in a lot of FOSS situations these days.

There's certainly been lots of innovation in server-side web frameworks and ORMs in PHP and Perl since the 90s. I can't speak to Perl but Slim is a good PHP microframework and Propel is a nice ORM, though there are also more heavy- duty frameworks such as Laravel.

If you don't mind learning a new language, I would recommend Python for any backend web development that doesn't require squeezing out as low response times as possible, which gives you the excellent Flask + SQLAlchemy, or Django if you prefer a little more hand-holding.

You can still use JavaScript to add interactivity without making a SPA. jQuery, Backbone, and React would do that in increasing levels of abstraction.

In the grand scheme of things, the changes to HTML/CSS since the 90s have been relatively small. If you use Bootstrap you might not even have to worry about them too much.

In summary,

\- MySQL or Postgres

\- Generate HTML server-side starting with a PHP or Python microframework and ORM, upgrade to a batteries-included framework if you discover you need it

\- Use Bootstrap

\- add interactivity with jQuery or (if you want to learn it) React (React- Bootstrap is nice); switch to full SPA if you discover you need it (in that case you'll probably want react-router, SystemJS, and JSPM)

\- use Heroku or equivalent to avoid system administration

\- with the combination of cross-browser libraries (jQuery, React) and the latest versions of all the popular browsers having fewer and fewer inconsistencies, you actually don't need to worry too much about how to support multiple browsers unless you want to support really old browsers that only make up a few percent usage share combined.

</comment><comment><USER11> There is nothing you need to do that you couldn't do with tools from 1999. Nothing. And your users will be amazed at how fast and functional your sites are.

Well OK there are some nice icons in Bootstrap, use those.</comment>


Ask HN: "Give the hardest job to the laziest person" - <AUTHOR> The saying goes "Always give the hardest job to the laziest person because they will find the easiest way to do it".<p>What is the best real-life example to this you've seen? <comment><USER2> _"I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities._

 _Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous."_

\-- General Kurt von Hammerstein-Equord, 1933 ([https://quoteinvestigator.com/2014/02/28/clever- lazy/](https://quoteinvestigator.com/2014/02/28/clever-lazy/))

</comment><comment><USER3> This is an example of the opposite "hard problem"

I was at a VERY EARLY startup that built telemetry and stored data. Anyway, the micro SD cards we purchased weren't formatted correctly.

The CEO told me I had to get them all formatted. He was slightly pissed at me for something or other, the guy was a genius but consistently flew off the handle.

I sat there looking at these racks of SD cards, there were more than 500 of these little fuckers to fumble with.

I did a small test and figured I was getting 1 done every 30 seconds depending on how fast the format went ect. Holy fuck I thought is this what I'm really doing right now?!

I said fuck, if i'm going to spend the next 4 hours doing this. I have a lot more important shit I want to do.

So, first I looked up the SD card reader we had and checked the specs. I noticed that itself could format the SD cards.

Next I called our firmware programmer and asked him how fast a rev would take to implement the functionality and give a rudimentary feedback that it was done and automatically perform the check during the boot sequence.

He says ... " OH wow, not more than 30 minutes I imagine."

I replied "Great! When can you have that to me?"

"I'll send it over to you in an hour" _click_

I then proceeded to bump his rev as the most recent firmware for our units that had to be eventually tested anyway and just walked away.

Hours later the CEO comes in and asks me why I'm not reformatting them (you're probably wondering why he's being such a micro managing baby, early on when i worked there he took his stress out in bad ways it got better later though).

I said I was done.

He said he didn't believe me.

I replied you're right I didn't do more than a few, because I made it so they'd all automatically do it going forward and that it'd be a good thing to have for a whole bunch of obvious reasons.

I don't even remember his reaction because I think I just remember us staring at each other before he walked away, only to then come back and show him how it worked so it wouldn't surprise him on a field visit.

<comment><USER4> Great story, although I really thought the punchline would be "Fast forward two years when a new firmware programmer took over, pushed a change that caused the rushed format detection to be skipped, and destroyed all our telemetry data on all readers."

</comment></comment><comment><USER5> Isn't this basically how startups work?

I built a full app to 1000 users in 2 weeks, to first payment and 5000 users a month after that. Keto recipes where we'd sell substitution ingredients.

Hardcoded the data. Didn't even have a shopping cart or payment gateway. We'd just query ordered items by the user phone number, and then give our bank details so that they could transfer.

Eventually we fixed it in a few months. But it was sufficiently complex, lots of content, low margins, physical items, which I still think is pretty impressive to get off the ground in a couple of months.

<comment><USER5> Also after acquisition, we tried to do it 'properly', with an improved business model, experienced developers, project/product management team. It ended up getting overengineered and we killed the project a year later.

<comment><USER6> what is the app? I've been doing keto and would be interested to check it out

<comment><USER7> Uh, did you read the comment you replied to?

> we killed the project a year later.

<comment><USER8> That says "the project", not the app/business/company.

<comment><USER5> Specifically, the original idea was split to two businesses - e-commerce order management and health/weight loss recipes/community. Both were killed.

</comment></comment></comment></comment></comment></comment><comment><USER9> Related [https://www.reddit.com/r/AskReddit/comments/ebp6ak/there_is_...](https://www.reddit.com/r/AskReddit/comments/ebp6ak/there_is_a_well_known_saying_that_goes_always/) from 2 days ago with 13.000 comments.

<comment><USER10> "Related" = Where they copied from.

</comment></comment><comment><USER11> It's a paraphrased Bill Gates quote isn't it?

I always choose a lazy person to do a hard job, they find an easy way to do it?</comment>


Hillary Clinton and the Blockchain - <AUTHOR> https://techcrunch.com/2016/07/07/hillary-clinton-and-the-blockchain/ <comment><USER2> If you pay her enough (donate to her campaign, the clinton foundation, or give her some cattle future trading tips) she'll say anything in her speeches. She's the most technically illiterate candidate of this century. Her emails (the ones she didn't delete) lay that bare.</comment>


How to Fix Error 651 in Windows - <AUTHOR> Please help me out to fix Error 651 in Windows...! <comment> chupa-chups \- [https://superuser.com/questions/303389/connecting-to-vpn- i-g...](https://superuser.com/questions/303389/connecting-to-vpn-i-get- error-651-the-modem-or-other-connecting-device-has)

\- [https://www.tp-link.com/us/support/faq/439/](https://www.tp- link.com/us/support/faq/439/)

\- [https://www.quora.com/Why-does-error-651-occurs-in- windows-8...](https://www.quora.com/Why-does-error-651-occurs-in-windows-8-1)

<comment><USER2> I don't think encouraging this kind of behavior by helping is a good idea.

<comment><USER3> Agreed. This is not a tech support forum.</comment></comment></comment>


Gitlab 9.0 - <AUTHOR> https://about.gitlab.com/2017/03/22/gitlab-9-0-released/ <comment><USER3> The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance.

But one change that _I_ did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.

<comment><USER4> Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: [https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk...](https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk/view)

There are some controller timings that are red [https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV...](https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZVZiRXFLOWNVQTA/view?usp=sharing)

And the git access timings are a sea of red [https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz...](https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTzg3NFN4UXU3Qmc/view?usp=sharing)

Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.

<comment><USER5> I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

<comment><USER6> Is Sublime really an editor of choice if speed comes first?

<comment><USER7> Well, compared to Atom, yes. Two somewhat similar tools with trade offs between them, one of them being speed.

<comment><USER8> Note that Atom is written in Javascript, so the run time is extraordinarily CPU heavy. Even though many Electron (Javascript desktop framework) apps may have snappy UIs, they're typically even worse than Java for CPU (battery life, etc).

<comment><USER9> btw: Sublime Text is written in C++, so the performance might be even better than Java.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I love and use Gitlab and am excited about the 9.0 performance improvements.

On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abuse your customer support addy to ask if somebody could force the maintainer to respond before the code rots. By that time the original submitter (who in comparison turned out to be easy to contact and collaborate with) was long gone. And another user had already announced a separate script they developed and maintained to work around the lack of merging this fix.

I'm glad it finally got merged, but it was only after deciding to use my free time and treat the process as a kind of game to be beaten. But that's a one- off game I won't play again. Plus I doubt the original submitter, a Go developer, will be making another merge request.

Anyhow, I made a list on the relevant issue tracker of the work it took to get the maintainer to eventually click the "merge" button: [https://gitlab.com/gitlab-org/gitlab-ci-multi- runner/merge_r...](https://gitlab.com/gitlab-org/gitlab-ci-multi- runner/merge_requests/313)

<comment><USER11> Hi janciska,

Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for doing that! From our side, we will try our best to make this process to be more efficient.

Kamil, CI/CD Lead at GitLab

<comment><USER10> Hi Kamil, Thanks for the reply.

One point may not have been clear-- this isn't just a matter of a single bugfix being available to the userbase sooner rather than later. Rather, it is that multiple iterations through a development cycle were missed. From my rough recollection:

1\. There was a problem setting up an OSX guest to work with virtualbox runner on OSX with passwords. We worked around this using pubkey-based auth between guest and host.

2\. There was also a timeout issue mentioned on the tracker for which Sam found the relevant code and suggested (but did not create) a fix.

3\. Sam seemed to think a snapshot-reuse approach was too complex and likely to hang or fail. I didn't agree and was trying to explore ways in which they could run reliably as it cut CI time in half for my use case.

4\. For uploading artifacts, the OSX guest's gitlab-runner binary had the wrong name requiring the user to manually create a symlink with the correct name. (I think this is fixed in 9.0, but not sure since I still have the symlink there and it's still working.)

At the time my CI builds (and probably Sam's) weren't working _at all_ , so we both ate the cost of learning how the CI build system worked in order to debug it. If there had been feedback saying that his MR was the right (or wrong) approach I would have been happy to apply my knowledge gained at the time to the related problems mentioned above in order to debug and eventually fix them.

But now that knowledge is gone. The cost for me to regain it outweighs the benefits of small improvements to what is atm a working if imperfect system.

Edit: formatting

</comment></comment></comment><comment><USER12> We've been using gitlab for most VideoLAN projects, and are moving towards it for all of them (including vlc and x264). A lot of things are great, and going in the right direction, but the issues tracker is really lacking.

The lack of custom fields, that you find in all other bugtrackers except github, and the lack of dependent issues are really blocking us to move full to gitlab.

And the biggest issue is that they're discussing to do it, but only in the non-open-source version, which we cannot use...

<comment><USER4> Thanks for using GitLab. We have open sourced features based on your request before [https://news.ycombinator.com/item?id=10931690](https://news.ycombinator.com/item?id=10931690)

I can't promise anything regarding these features. Especially custom fields are a typical EE feature in our perspective. The dependent issues feature proposal [https://gitlab.com/gitlab-org/gitlab- ce/issues/4058#note_249...](https://gitlab.com/gitlab-org/gitlab- ce/issues/4058#note_24946893) is still on the CE tracker but I'm not sure what it's future is.

<comment><USER12> Don't take me badly, Gitlab is the best thing around. We've tested many solutions... (too many)

It's just that I really want to quit using trac, who is slow and not integrated with the rest of the infrastructure.

<comment><USER4> No worries, we love you too! Our Product Manager Victor Wu will email you to learn more.

</comment></comment></comment></comment><comment><USER13> For anybody else wondering where that gorgeous cover photo is from: Queenstown, New Zealand :-)

[https://about.gitlab.com/images/9_0/9_0-cover- image.jpeg](https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg)

[https://www.google.ca/search?q=queenstown+new+zealand&source...](https://www.google.ca/search?q=queenstown+new+zealand&source=lnms&tbm=isch)

</comment><comment><USER14> Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more.

I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a single place. A board that is visible at a group-level would solve this problem.

I believe this is a feature that's coming soon, though. I am looking forward to it.

<comment><USER15> Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop.

I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in its own company-specific repo. Then they put the whole thing in a "UI kit" which realistically they will never reuse.

<comment><USER16> We originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.

</comment></comment></comment><comment><USER17> Gitlab was really promising for my colleagues and I, but its inability to host git repos on the url root (aka gitrepo.mycompany.com/product.git) without hacking means its a no-go as we're not particularly inclined to redo all our development, deployment, and testing infrastructure. We use git a lot in our organization, including customer-facing stuff, so it would be a large transition.

Also stubborn coworkers who don't want to monkey with git settings.

Which is a shame, I really like gitlab and would love to replace gitolite :/

<comment><USER18> What if you just set up an nginx reverse proxy?

gitrepo.mycompany.com/product.git --> reverse proxy to git.mycompany.com/gitrepo/product.git

Should be straight forward in nginx

<comment><USER19> Just curious since I am not experienced with this stuff, are you talking about a TCP reverse proxy (so it could work with the SSH protocol too)? And would haproxy work equally well to nginx for this?

<comment><USER20> If I remember right, nginx doesn't support ssh + http(s) on the same port. I'd be happy to learn this isn't correct, though because my personal server only is allowing http through.

<comment><USER17> Generally speaking, you cannot bind more than one service to a port on a given interface

<comment><USER20> Yeah, that's the issue i had ran into. I was `listen`ing on 80, but wanted to multiplex ssh+http on the same port and nginx didn't support it.

</comment></comment></comment></comment></comment></comment><comment><USER21> As much as I love GitLab the UI/UX is still very weak compared to GitHub. And the sidebar change is something in the completely wrong direction. You should also really check out how it looks on a 4k screen.

<comment><USER22> Well, IMO the Github UI has been taking some steps backwards recently. If Gitlab keeps improving and Github worsening, they'll be at parity before too long

<comment><USER4> We certainly don't want to win in a race to the bottom.

To get an idea what our UX team is working on please see their update from this Monday:

Video [https://www.youtube.com/watch?v=TMdw- plNfDQ](https://www.youtube.com/watch?v=TMdw-plNfDQ)

Slides [https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF...](https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF_HEsbP8OEfW3p6WbdNSkozU/edit?usp=sharing)

<comment><USER22> I imagined you'd meet in the middle, rather than at the bottom!

I like what you guys are doing - my comment was more meant as a well-natured jibe against the recent Github changes, which I'm _really_ struggling to like (the black header a few weeks ago, and today the search results interface).

<comment><USER4> Ah, sorry for misreading it, I get caught up in the release excitement. <3

</comment></comment></comment></comment></comment><comment><USER23> What convinced me to try out gitlab today: "Today with 9.0, we are excited to release Deploy Boards for environments running on Kubernetes. The Environments page of Pipelines now offers a single place to view the current health and deployment status of each environment, displaying the specific status of each pod in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes."

<comment><USER4> Great to hear that. Deploy boards is one of the few features that came from our own vision more than customer requests. So we're very happy to get validation that this is something people need. GitLab 9.1 will have canary deploys and an automatically deploy board to make deployments even better.

<comment><USER24> Is there an api for users that might want to integrate alternative schedulers for these features? Would be _lovely_ to be able to integrate Nomad somewhat natively.

<comment><USER25> No, but we're hoping to work together with the community to make all these features available on all major platforms [0].

One thing that we're seeing is that most schedulers are moving towards supporting Kubernetes, which goes a long way in making this work there. Right now we support Kubernetes through Google Container Engine or via Openshift.

[0]: [https://gitlab.com/gitlab-org/gitlab- ce/issues/20199](https://gitlab.com/gitlab-org/gitlab-ce/issues/20199)

</comment></comment></comment></comment><comment><USER26> Any documentation / talks / videos about the gitlab + kubernetes integration ? Thanks for the awesome product. At work we switched to gitlab for new projects and loving.

<comment><USER27> Thanks for switching to GitLab, glad to hear you're loving it! :D

We have this demo from our most recent summit where we put together an entire GitLab instance in ~20 minutes on a Kubernetes cluster, though I'm not sure that's exactly what you want? [https://about.gitlab.com/2017/01/23/video- tutorial-idea-to-p...](https://about.gitlab.com/2017/01/23/video-tutorial- idea-to-production-on-google-container-engine-gke/)

We also have some documentation on integrating with Kubernetes here: [https://docs.gitlab.com/ee/user/project/integrations/kuberne...](https://docs.gitlab.com/ee/user/project/integrations/kubernetes.html#gitlab- kubernetes-openshift-integration)

<comment><USER28> The integration with Kubernetes looks pretty cool so far. Is there any consideration being given to integrating with Docker Swarm Mode?

<comment><USER29> We're hoping to work with the community to support all container schedulers [1].

But right now we're focused on deepening the integration on Kubernetes so it's a great end-to-end experience.

[1]: [https://gitlab.com/gitlab-org/gitlab- ce/issues/20199](https://gitlab.com/gitlab-org/gitlab-ce/issues/20199)

</comment></comment></comment></comment><comment><USER30> I like Gitlab, as an absolute noob I'm not really ready to make every mess of a program I use public (as Github requires). I fear that it can and will be used against me. I'm also such a small time user I think paying for Github is too much for my 3 > 200 lines projects. And so you end up at Gitlab. It works very well for me. If I want to, in the future, I can host it myself which is a nice thing. From this update I most like the dark-themed code view, yes I'm a simple man that is just learning how to code.

</comment><comment><USER31> I would love to upgrade on my GitLab server, but I haven't been able to build GitLab with the omnibus builder since 8.14. I opened up a ticket but it hasn't garnered a response.

[https://gitlab.com/gitlab-org/gitlab-omnibus- builder/issues/...](https://gitlab.com/gitlab-org/gitlab-omnibus- builder/issues/7)

<comment><USER25> It seems the issue is on the wrong issue tracker. Our omnibus lead Marin will make sure that it lands in the right place and gets some attention (see the comment from ZJ).

Edit: more info in the issue you've posted.

</comment></comment><comment><USER32> With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially be a band-aid. I (and others) have requested it before, but was told it was too low of a priority and it wouldn't be worked on.

<comment><USER33> I'm afraid it gets a little worse. In an attempt to simplify some of the settings pages, deploy keys were moved onto the repository settings page.

[https://gitlab.com/gitlab-org/gitlab- ce/issues/29667](https://gitlab.com/gitlab-org/gitlab-ce/issues/29667)

We need to do something about this very soon, so please keep an eye on that issue.

We're going to be doing some more work on settings pages, hopefully in 9.2 and make them a lot better.

[https://gitlab.com/gitlab-org/gitlab- ce/issues/28451](https://gitlab.com/gitlab-org/gitlab-ce/issues/28451)

<comment><USER32> So they are on the main Project Settings page as of 9.0? If that's the case, we will avoid upgrading until that is changed because that page will become fairly unusable in our case, both in terms of speed and general UX because our Deploy Keys page is currently 20,777px tall. That is a lot of scrolling to have to deal with.

I will subscribe to those issues and hopefully it will improve. As of now, though, that is a complete non-starter for us.

<comment><USER33> No not the main project settings page. Settings -> Repository and it's right at the bottom, so no more scrolling than you are used to.

</comment></comment></comment></comment><comment><USER9> No more fixed header and pages properly reload when I click on a link (spinning icon in the tab). Awesome! These were my major UI gripes in GitLab 8.

<comment><USER4> Awesome! This is because we removed turbolinks [https://about.gitlab.com/2017/02/06/vue-big- plan/](https://about.gitlab.com/2017/02/06/vue-big-plan/)

</comment></comment><comment><USER34> I've looked at their website. Is Gitlab basically a self hosted Github and Heroku style (app containers) like product?

<comment><USER35> If you host it on top of a Kubernetes cluster, yes. Github (including kanban boards) + CI + Heroku (including deployments, workflows) + now even Monitoring.

They are selling what one might call an "Omakase" experience for the whole SDLC. They call it "Idea to Production".

<comment><USER4> That is a very apt description, thank you for that. We're really inspired by the Rails doctrine [http://rubyonrails.org/doctrine/](http://rubyonrails.org/doctrine/) and think that the Software Development LifeCycle (SDLC) has room for a solution with convention over configuration.

</comment></comment></comment><comment><USER36> I am having problem with de CI/CD after update:

``` Running with gitlab-ci-multi-runner 9.0.0[...] Cloning repository... Cloning into '/builds/xxxxxxx'... warning: You appear to have cloned an empty repository. Checking out xxxxxxx as master... fatal: reference is not a tree: xxxxxx ```

<comment><USER36> I rebooted de entire machine and it is working now

<comment><USER4> Thanks for reporting back, glad to hear it is working now.

</comment></comment></comment><comment><USER37> The new enhancements seem very promising. We've been using gitlab for our internal use for a while now.

Having said that, every time a new gitlab release comes around, I always looks for updates in one area expectantly but mostly left unsatisfied. And that is, separation of the concept of Project from "one git repo"

E.g., I want to manage a project that ties in issues from various different git repositories. It's pretty common. Almost no actual "project" in a real life business is limited to just one git repo.

I want a system-wide wiki that collects knowledge about the entire operations. The idea that each wiki is tied to a particular git-repo is.. just... wrong.

Heck, even the new search feature across projects somehow doesn't include wiki's. How did that decision get made?

And so on and so forth.

<comment><USER25> One of the high level goals I set for this year is scaling up to projects that consist of more than a single repository.

That means CI that spans multiple projects [0], higher abstraction of issue management [1], formal relationships between issues [2] and more.

Having a global wiki or higher level wiki should also be part of that [3], I think.

[0]: [https://gitlab.com/gitlab-org/gitlab- ee/issues/933](https://gitlab.com/gitlab-org/gitlab-ee/issues/933)

[1]: [https://gitlab.com/gitlab-org/gitlab- ee/issues/928](https://gitlab.com/gitlab-org/gitlab-ee/issues/928)

[2]: [https://gitlab.com/gitlab-org/gitlab- ce/issues/4058](https://gitlab.com/gitlab-org/gitlab-ce/issues/4058)

[3]: [https://gitlab.com/gitlab-org/gitlab- ce/issues/4037](https://gitlab.com/gitlab-org/gitlab-ce/issues/4037)

</comment></comment><comment><USER38> Ah! Finally found the culprit :-)

I run my fleet of runners in pre-emptible instances on GCP (they die after 24h).

I forgot to pin the version in my startup script, so all it did was a simple apt-get install gitlab-ci-multi-runner.

For some reason, version 9 of the gitlab runner cannot connect to our Gitlab (it fires a 404 on register).

Anyways, look like 9 is a cool release, but we won't be upgrading until the sidebar comes back (did a little poll in the team and it 100% was in favour of the sidebar)

<comment><USER39> maktouch: Runner can't connect to GitLab because version 9.0 of Runner requires GitLab 9.0. We've noticed this in the release blog post: [https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#git...](https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#gitlab- runner-deprecation) :)

The reason is that in 9.0 we've prepared a new API for Runner requests (as part of new v4 version of API) and Runner 9.0 is using only this version.

Version v1 of the CI API is still supported by Runner 1.10.X and 1.11.X. On GitLab's side it will be supported until August 2017 and until then we will also support Runner 1.11.X.

</comment></comment><comment><USER40> Jesus, they're killing it.

</comment><comment><USER41> Awesome release!

What do people use to keep up to date with all the non-stop Gitlab releases? I used to use sandstorm but their port is very outdated by now (same goes for bitnami). I switched to cloudron and it has served me well but I am always on the look out for other solutions. On a side note, if you use the omnibus packages, are you a full time (or even part-time) sysadmin?

<comment><USER42> Using omnibus (with backups), it's as simple as an 'aptitude upgrade' for us

<comment><USER41> Have you just setup a cronjob for backups? And do you also test somehow that those backups work (or rely on gitlab doing the right thing?) Or maybe you use server snapshots? Also how how did you go about SSL?

</comment></comment></comment><comment><USER43> I'm surprised, impressed, and frankly amused in that you can sign into gitlab.com with your github account.

<comment><USER25> Glad to hear that. You can also import your projects directly (everything will be copied over).

We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.

<comment><USER44> _> You can also import your projects directly (everything will be copied over)._

I had forgotten about that, thanks for the reminder.

I'll be moving all my stuff over this weekend once I curate out the things I don't _actually_ use over on Github...

</comment></comment></comment><comment><USER45> I wonder if this will provide a benefit in a resource constrained environment. I run the official Gitlab Docker/gitlab-ce container in a host with a J1900 processor and 4GB RAM and it is barely usable. Most pages timeout on the first load.

At present it looks like it hasn't been updated since 2015.

<comment><USER46> Currently running gitlab over docker on a dedicated 8 core system with 32G of ram, it routinely uses 9G of that for barely 30 users. (it's the only thing running on that physical host)

So, keep that in mind.

<comment><USER47> Which version of gitlab? Didn't they reduce memory demands in a recent release?

<comment><USER46> I keep it updated; it's now version 9 and still consuming 7G

                    total       used       free     shared    buffers     cached
       Mem:         31974      13984      17989         12        871       6047
       -/+ buffers/cache:       7066      24907
       Swap:        16367

The UI counts 10G for some reason.

[http://i.imgur.com/edAceQx.png](http://i.imgur.com/edAceQx.png)

<comment><USER48> Our omnibus package tries to use a % of your total memory for cache, so one way to reduce memory is fine tuning it. See for reference: [https://gitlab.com/gitlab-org/omnibus- gitlab/blob/master/fil...](https://gitlab.com/gitlab-org/omnibus- gitlab/blob/master/files/gitlab- cookbooks/gitlab/attributes/default.rb#L373-380)

</comment></comment></comment></comment></comment><comment><USER49> The sidebar took a step backward in my opinion. I am missing the 'pin' option.

<comment><USER16> Thanks. Feel free to add feedback to the ongoing discussion here: [https://gitlab.com/gitlab-org/gitlab- ce/issues/29835](https://gitlab.com/gitlab-org/gitlab-ce/issues/29835).

<comment><USER50> Why did you remove the sidebar + pin again??

When you removed the sidebar last time - users of GitLab lobbied you hard to get that pin in there so they could keep that sidebar open at all times.

These kind of changes make me feel like you're not understanding (respecting) your customers' needs (desires).

<comment><USER50> Sorry just to be clear - I really like GitLab - and I feel GitLab tries hard to make a great product for their users - and clearly they have a good understanding of the development community. It's just that I felt this issue had already been discussed and resolved - to be yet again undone. So just feeling frustrated we have to go through this again.

</comment></comment></comment></comment><comment><USER51> Any idea how I can upgrade my docker installation on Kubernetes? At the moment in my Helm chart i have specified exat Gitlab and Postgresql version. Do i need to bump postgresql too when changing Gitlab?

</comment><comment><USER52> how is the CD in Gitlab complete without this issue being complete ([https://gitlab.com/gitlab-org/gitlab- ce/issues/28497](https://gitlab.com/gitlab-org/gitlab-ce/issues/28497)) - <USER2> there any alternative if i want to use "gitlab.com" for hosting my code ?

<comment><USER4> Most of CD including deployments already works for private projects, it is only the auto deploy [https://docs.gitlab.com/ee/ci/autodeploy/index.html](https://docs.gitlab.com/ee/ci/autodeploy/index.html) that doesn't work yet. We would all like to see auto deploy working with private projects and it is scheduled for 9.1

If you don't want to use GitLab.com to host your code you can install GitLab yourself or use the mirroring function in GitLab to deploy code hosted elsewhere.

<comment><USER52> will just wait for "Gitlab.com" to get the functionality - is there any lag between Gitlab version upgrade and "Gitlab.com" using the upgraded Gitlab version ?

Will wait it out for Gitlab 9.1 :) Thank you for the amazing work.

<comment><USER4> GitLab.com has RCs weeks before the official release.

And you're welcome.

</comment></comment></comment></comment><comment><USER53> Anyone know where that restaurant in the picture is? Looks amazing!

<comment><USER53> Found it: [https://www.omegarentalcars.com/support/blog/queenstown- luge...](https://www.omegarentalcars.com/support/blog/queenstown-luge-and- skyline-gondola/)

</comment></comment><comment><USER21> You guys should look into your search functionality as it's not working for hours already :)</comment>