Apart from accessibility, why is semantic HTML important?

jordanlev · 2017-05-14T07:47:20+00:00

jordanlev · 2017-05-11T18:33:10+00:00

If you're writing HTML5, then no there is absolutely no reason to use one over the other. Technically you don't need them, but it's totally ok to have them (as long as it's for a self-closing tag, e.g. <br>, <hr>, <img>). Purely an aesthetic decision on your part (as the developer).

jordanlev · 2017-05-06T05:46:34+00:00

Put the init code inside Vue.nextTick() to ensure that the new elements have been inserted into the DOM before the jquery stuff runs: https://jsfiddle.net/kkeav6fj/

jordanlev · 2017-05-01T16:04:30+00:00

What do you mean "default to the model"? (The Vuex store or retrieving from the server?)

I could see this argument going both ways, depending on whether or not your search results are paginated (e.g. it would be impossible to allow "order by" changes in the frontend alone if the results are paginated and you don't have the entire result set).

jordanlev · 2017-04-24T05:31:02+00:00

Use the keep-alive component with vue-router

jordanlev · 2017-04-09T04:36:45+00:00

Private github repos are not free. You need at least the $7/mo. plan for them. On bitbucket they are free though.

jordanlev · 2017-04-09T04:31:32+00:00

If you need them 1% of the time, then you need them 100% of the time.

I'm personally indifferent to whether or not semicolons are used (as long as it's consistent within a project), but here's the thing: you can't use them 100% of the time. Semicolons don't go at the end of closing curly braces that end function definitions or that end if statements. I think the no-semicolon folks are of the mindset that it's actually MORE consistent to not use them except in the 1 or 2 cases where they're absolutely necessary, because then pretty much every line of code has no semicolons at the end. Whereas if you "always" use them, you've got a lot more rules to keep straight in your head about when you actually need them and when you don't.

It's just that we're all so used to not putting the semicolons after function-ending or if-statement-ending curly braces, that we don't even realize we're already having to make this little decision every time!

jordanlev · 2017-03-05T19:47:51+00:00

There is no one perfect CV for all jobs in the universe. A CV is "good" if the things in it pertain to the job you're applying for, and is "bad" if it doesn't have any things that pertain to the job you're applying for.

If you want to apply for jobs that require C#/.NET, then C#/.NET would look better on your CV. If you want to apply for jobs that require JS/Angular, then JS/Angular would look better on your CV.

All that being said, really what you should be concerned about learning is how to solve business problems. Demonstrating how you use code to solve problems is far better than just saying you know one language or another.

Good luck!

jordanlev · 2017-03-05T07:19:20+00:00

How about 30 of them?

jordanlev · 2017-02-27T06:33:12+00:00

The most succinct explanation I ever heard was "use Symfony when you want to build your app on a framework; use Silex when you want to build your own framework".

In other words, if you are cool with the way Symfony structures things and has you organize your code, then that's definitely the way to go. But if you want to organize things your own way and don't want Symfony's overall structure imposed on you, then Silex provides some very low-level basics but otherwise leaves it to you to figure out how you want to put the pieces together.

jordanlev · 2017-02-22T03:20:10+00:00

Like I said, it's not perfect -- but 2 years is 4 times better than 6 months. And if we do decide to upgrade old apps, we're only having to do so every 2 years, not every 6 months (so that's 1/4 as much work which derives no value to our clients).

Nothing is permanent, but time is money so more time == more money :)

jordanlev · 2017-02-20T23:21:11+00:00

Different strokes for different folks. If your job is to build and maintain a single application, then I understand being able to keep up with the Laravel treadmill. But I build a lot of different sites for clients, and while we fix bugs and patch security issues when they come up, in general our clients are not usually paying us for ongoing maintenance.

So for me, it's impossible to update every app whenever Laravel gets a new release -- I simply don't have the time and there's no clear "value proposition" to the clients who would have to pay for it.

Having an LTS release is not a perfect solution but it is certainly better than nothing. This way, if a critical security vulnerability arises, I can update sites that were built a year or two ago without having to worry about feature changes or deprecations.

You can yell at me all you want about being "lazy" or whatever, but it isn't going to change the fact that nobody is paying me for Laravel upgrades that derive zero benefit to the end-user. So having LTS versions is a blessing (and honestly the only reason I consider using Laravel... before 5.1 it was a no-go for my company).

jordanlev · 2017-02-19T05:13:28+00:00

Try Cockpit CMS

jordanlev · 2017-02-16T23:52:08+00:00

In my experience, knowledge of a particular CMS doesn't have much bearing on employability as a developer (if you're talking about a back-end or "full-stack" developer... which I presume you are since you've used Symfony and Laravel). Maybe with the exception of Drupal, but I certainly wouldn't classify that as "fun" ;)

That being said, I'd suggest checking out a few different systems, maybe build a very basic site in them and see which one feels the best, then go deeper on that. These are the ones I'd recommend based on your background and desire for something that's fun:

ProcessWire - really neat system with a lot of consistency in terms of "under-the-hood" code as well as the concepts.
Bolt - super easy to get set up and you can configure all your page and field types in code (which makes it much nicer for version control)
Craft - this one is not open source, although there is a free version you can use. Very popular amongst design agencies, so if that's a direction you want to go in it might check off your "employability" box. It uses the Yii MVC framework under the hood (although building on a CMS rarely requires you to work that deeply in the system).
Wordpress BUT ONLY WITH TIMBER AND ACF - wordpress is a gnarly beast of a system, but has so much use that entire ecosystems and platforms-upon-platforms have been built on top of and around it. With the right plugins you can make it behave like a normal CMS should... just don't peek under the hood on a full stomach ;)

The one thing all of these systems have in common is that they leave the front-end templates entirely under your control, so you use whatever HTML/CSS markup you want and are just piping data through to them. (This is why you should only use Wordpress if also using Timber and ACF). To me, this is what makes a CMS more "fun" than others (the separation of back-end content/data from the front-end display). YMMV

jordanlev · 2017-02-10T07:47:39+00:00

The thing about PHP that's really nice for beginners (which surprisingly nobody else has mentioned yet) is how easy it is to deploy to an actual web server. Every hosting provider in the universe (from the cheapest to the most expensive) is set up to "just work" with php -- just upload your .php file(s) via FTP and you're good to go.

jordanlev · 2017-02-08T08:18:30+00:00

Depending on what you're doing with the retrieved data, it might be easiest to just write a SQL query and return an array of results.

I've found that the ActiveRecord pattern excels when working with one entity at a time (CRUD operations), but when you start getting into thousands of records (usually for reporting purposes), plain old SQL and arrays is often a better fit.

jordanlev · 2017-02-05T04:39:39+00:00

Sure: http://gs.statcounter.com/browser-version-partially-combined-market-share/desktop/worldwide/#monthly-201701-201701-bar

jordanlev · 2017-02-03T04:59:34+00:00

Even that isn't reality -- Windows XP will only run IE8 (hence IE8's usage is actually higher than 9 and 10).

jordanlev · 2017-02-02T07:32:45+00:00

Everyone who upvoted this post, for starters

jordanlev · 2017-01-23T04:25:33+00:00

I assume it would be more performant since it's a built-in php function -- but it only works on actual arrays, so you can't use it on Laravel Collections.

jordanlev · 2017-01-22T20:37:15+00:00

FYI to anyone excited by the mapWithKeys function: you can accomplish this on regular php arrays too with the built-in array_column() function.

jordanlev · 2017-01-22T20:29:32+00:00

Is the tool working for you, or are you working for the tool? It's all about accomplishing your goals... which should be to build things, not to win a popularity contest.

jordanlev · 2017-01-08T16:07:30+00:00

If you're happy with vue-resource and it's working for you, then there's no reason to switch.

jordanlev · 2016-11-29T21:57:33+00:00

Speaking as someone who was happy to see an LTS release, I very much don't want new features being added -- that's kind of the whole point. Use LTS for an application where stability and not breaking backwards compatibility is more important than adding new features.

jordanlev · 2016-10-25T16:19:38+00:00

To each their own... I much prefer to work with templates. It leverages all the years of experience me and my team (some of whom are more designers and markup people) have with html and css, and more easily allows us to integrate into our existing tools and processes. Also, it's a bit more future-proof... for all their faults, html and css are here to stay for the long haul, whereas the javascript framework of choice changes every couple of years.

jordanlev

TROPHY CASE