|
I think I may modify the tab below. I figure as long as the color is there, they won't mind it not 100% being colored. Color on the left 1/4 of the tab, then white on a dark bg for the remaining 3/4.
|
#
?
Jan 21, 2016 22:56
|
|
|
|
| # ? May 8, 2024 06:09 |
|
|
kloa posted:I really dislike the look of text-shadow, in an otherwise flat-design, but I can't really find a better way to display white text on a light background, such as yellow. Use a transparent not quite black shadow with 0 offsets and a big blur. Something like rgba(15, 15, 10, 0.5) 0px 0px 6px to start then play with the blur until it looks as least like crap as possible. Then hire a better designer for next time.
|
|
#
?
Jan 22, 2016 06:35
|
|
|
Lumpy posted:Use a transparent not quite black shadow with 0 offsets and a big blur. Something like rgba(15, 15, 10, 0.5) 0px 0px 6px to start then play with the blur until it looks as least like crap as possible. Then hire a better designer for next time. Cutting the transparency to 0.3 from 1 did help make it not look as terrible  Also it was me, I am the terrible designer 
|
|
#
?
Jan 22, 2016 17:12
|
|
|
I hope this is the right place, looking for some insight. I just graduated with a BSc in compsci and I've been offered a frontend position at a startup, which is owned by a huge company in my country, for pretty decent pay considering I have no real-world programming experience. I'll be using JavaScript, React, Async, and Redux, and will apparently be given some exposure to backend (my preference) and mobile development. Now the hosed up part, I never used any of those technologies throughout my degree. The last three I'd never even heard of until I started researching after the interview. I was very up-front about my experience and was assured it wasn't an issue, though I was made aware that I "will be learning a gently caress load". The whole thing seems bewildering to me but I'm committed now, or at least intend to be after I receive the contract and it checks out - provided I'm not about to make a stupid mistake. That said, one of my circle of friends is made up of mostly mid-senior developers and a couple architects who've all seen my work, and assured me that I'll be fine. So far, I've picked up the javascript fundamentals from Codecademy and I'm in the process of trying to wrap my head around React from the obvious resources I could find, and I'll be spending the weekend doing the same for Async and Redux. I'm also in the process of building every basic javascript app I can find tutorials for. For reference, all my spare time is spent with coding, at the gym, gaming, or with the missus so I'm not worried about being able to fit in a lot of research and practice in my own time, after work, as it'll probably be necessary. My question - am I hosed, or is it likely that since I have no experience outside of uni I'm overthinking the difficulty of being thrown into several technologies I've never heard of? Finally, could anyone recommend some learning resources for the four things I've listed? Thanks.
|
|
#
?
Jan 28, 2016 09:07
|
|
|
Whatever happens just remember you did the right thing and you were honest with them about your experience. Then tell the employers to stop obsessing so much over formal qualifications when you inevitably gently caress up. I'm kidding, I'm sure you'll be fine. But be wary of a company that hires on qualifications alone.
|
|
#
?
Jan 28, 2016 09:25
|
|
|
Also I'm incredibly jealous.
|
|
#
?
Jan 28, 2016 09:26
|
|
|
The Wizard of Poz posted:Whatever happens just remember you did the right thing and you were honest with them about your experience. Then tell the employers to stop obsessing so much over formal qualifications when you inevitably gently caress up. The Wizard of Poz posted:Also I'm incredibly jealous. Thanks! I'm incredibly wary but hopefully that's just me overthinking the situation.
|
|
#
?
Jan 28, 2016 09:40
|
|
|
Honestly, fake it til you make it is a surprisingly accurate meme when it comes to web development.
|
|
#
?
Jan 28, 2016 09:41
|
|
|
Click Beelay posted:words You'll be fine. We hire for front-end entry-level jobs out of college and all that's expected is "isn't horrible to work with" and "eager to learn". Every front end developer should read and know "JavaScript The Good Parts" and "Secrets of the JavaScript Ninja". J:TGP is a good intro to JavaScript for someone with a CS degree, let that sink in for awhile then move on to SotJN. Keep in mind Crockford and Resig are humans and have bad opinions on some things, but they're good enough that you can trust 98% of what they say now, and slowly realize they could be wrong on the other 2% further down the road. Your degree taught you about MVC probably? If not do a quick refresher on separation of concerns and why MV* is the predominant pattern in software development these days (and don't get hung up on whether the stack you're using is MVC/MVVM/MVW/etc). React is just a view library (the 'V' in MVC) that creates DOM elements for models, and updates the elements for you when the model changes. A fun exercise for a rainy night would be to do the official React tutorial and then try doing the same thing with plain JavaScript using the DOM API. You'll quickly realize the DOM API is horrible and that's why the last 5+ years of web development have been all about frameworks and libraries that try to make your life easier when using a language with a bare bones standard library and a crappy API. Redux is there to help you with managing the state of that model, since React leaves that up to you. Async vs sync was one of the hardest things for me to grasp as a noob. It primarily matters in UI or apps where you do expensive computations or network/disk reads. UI example flow of code: 1. Draw form fields 2. Get input from user 3. Hit a database for a bunch of data 4. Run expensive computations on data based on user's input 5. Display results With synchronous code, those steps all happen in order. You need to wait for 3 to finish before starting 4, etc. Now the app is doing a bunch of other stuff like rendering to the screen, allowing users to do other things, resize windows, and more. When #3 and #4 are synchronous, everything else is held up waiting for those to complete, so your app appears unresponsive. Unresponsive UIs shouldn't exist in 2016. With a web service you have similar issues: 1. Receive request 2. Call other network service to fulfill request - this takes 100ms on average for this particular call, but could easily time out, or take 1000ms, or whatever. 3. Return results Single-threaded apps will hit #2, stop processing other requests, and wait. Multi-threaded apps like ASP.NET will tie up a thread while waiting. Even in a multi-threaded scenario, if you get enough requests backing up, you can bring the app down. Whether its an event loop like node.js or an async state manager like in ASP.NET, async programming will defer these expensive requests and allow processing to continue, and when the async method is complete, then it resumes control from that point. Long story short, async is used to keep UIs responsive, and help servers process as many concurrent requests as possible. luchadornado fucked around with this message at 14:30 on Jan 28, 2016 |
|
#
?
Jan 28, 2016 14:26
|
|
|
Helicity posted:
I think he was referring to Async, not the general concept of asynchronous programming.
|
|
#
?
Jan 28, 2016 15:22
|
|
|
If it is a genuinely good company, they hired you because of your foundation knowledge, your problem solving methods, and your attitude. If a company is set up well, they have mentors that can help you out with getting better acquainted with the nuisances of frameworks / MVCs.
|
|
#
?
Jan 28, 2016 15:32
|
|
|
Click Beelay posted:I'll be using JavaScript, React, Async, and Redux, and will apparently be given some exposure to backend (my preference) and mobile development. At this point in my career (8 years), I specifically choose jobs where I'll get a chance to learn a new library, framework, stack, etc. I spent the last year building with Angular and earlier this month I started learning React / Redux. You'll be fine. Get used to continually learning new things, it will make you a better developer. As far as learning React/Redux specifically:
|
|
#
?
Jan 28, 2016 15:50
|
|
|
Click Beelay posted:I hope this is the right place, looking for some insight. You are as far from hosed as you can be. Congrats on a job in what i think is a great environment to work on! Here's a couple additional links I found informative useful to go along with sim's list (that egghead course is A++ stuff): https://medium.com/front-end-developers/handcrafting-an-isomorphic-redux-application-with-love-40ada4468af4#.tt4ac93bv http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html (I am jealous as well!)
|
|
#
?
Jan 28, 2016 15:57
|
|
|
since my last posts in here I've been playing around with redux-react a ton, and just making node server applications trying out the different libraries/design patterns etc. to see what I like. Does anybody have a preferred stack for this? So far I've found that I really like - node server - neo4j DB - node-neo4j library - react & redux with the react-redux bindings - redux-saga for async and delayed stuff - postCSS w/ rucksack (i'm not as familiar with these, other guy was playing around with it) - webpack & babel - chai for tdd - immutable for redux mutation safety Does anybody have anything to add/remove? I'm still really fresh in this realm, so I'm completely open to suggestions. The desired app is sort of a user/event management software, with heavy emphasis on relationship data & visualization of said data, hence the graph database.
|
|
#
?
Jan 29, 2016 00:05
|
|
|
I should probably sit down and figure out redux-saga but every time I try to read an explanation like this my eyes glaze over and I retreat back to redux-thunk which is more than enough for my basic HTTP request needs. That seems like a solid enough stack for what you're trying to do. PostCSS/Rucksack is pretty immature and I'd probably recommend SASS instead, but it's probably not something that's going to be annoying if you change your mind later.
|
|
#
?
Jan 29, 2016 00:10
|
|
|
Helicity posted:You'll be fine. We hire for front-end entry-level jobs out of college and all that's expected is "isn't horrible to work with" and "eager to learn". This is.. fantastic. Kekekela was correct about me meaning Async the module and not asynchronous coding; that said, now I have another thing to read up on since the only sync vs. async stuff I learned in uni was related to computer architecture. I've found JS:TGP and am feeling a lot more confident than I was yesterday. The React tutorial seemed a bit over my head after having just completed the Codecademy JS course but I spent the last hour or so knocking out the Angular one and now React kind of makes sense; also holy poo poo it seems powerful. Thanks a lot mate. The Dave posted:If it is a genuinely good company, they hired you because of your foundation knowledge, your problem solving methods, and your attitude. If a company is set up well, they have mentors that can help you out with getting better acquainted with the nuisances of frameworks / MVCs. It's a fairly small startup despite the amount of funding due to the parent company but again this is reassuring as hell, thanks. sim posted:At this point in my career (8 years), I specifically choose jobs where I'll get a chance to learn a new library, framework, stack, etc. I spent the last year building with Angular and earlier this month I started learning React / Redux. You'll be fine. Get used to continually learning new things, it will make you a better developer. As far as learning React/Redux specifically: Perfect! I fundamentally enjoy learning so this is great to hear. Thanks for the resources, now I definitely won't be running out of things to do in the near future. Lumpy posted:You are as far from hosed as you can be. Congrats on a job in what i think is a great environment to work on! Thanks! I'm starting with the egghead videos but can never have enough resources.
|
|
#
?
Jan 29, 2016 02:41
|
|
|
Click Beelay posted:I hope this is the right place, looking for some insight. You'll be just fine. Everyone has to start somewhere and it sounds like you are starting in a really excellent place. You were upfront about your lack of experience with the technologies they use, so there shouldn't be any surprises about it on their side. In some ways, that's a plus for them because it makes you malleable. I hired several people for mid-level development of an Angular app and I didn't give a poo poo if they knew Angular. I was more interested in them being sharp, communicating well, and knowing JavaScript. Frameworks come and go. My team was more than happy to teach them the ins and outs of the framework. One bit of advice: focus mainly on understanding JavaScript. React, Redux, and Async are all well-designed, sane, and relatively straightforward libraries. A Comp Sci grad shouldn't have too much trouble learning them. JavaScript, on the other hand, has many parts that are not particularly sane or well-designed (though it's getting somewhat better) and the language works quite differently than most other languages that have similar C-like syntax. You would be shocked to learn how many supposed web developers don't understand really basic aspects of the language, like variable scoping. Learn how JavaScript works and understand its quirks before you form an erroneous mental model of the language. Helicity's suggestions of "java script: The Good Parts" and "Secrets of the JavaScript Ninja" are both good. "Eloquent JavaScript" is also excellent and can be read entirely online: http://eloquentjavascript.net/. John Resig has an old, but quite good, "Learning Advanced JavaScript" course online: http://ejohn.org/apps/learn/. I would argue that a lot of it shouldn't be considered "Advanced" at all. When I interview candidates for JS roles, I ask a LOT of questions about the sort of concepts covered there.
|
|
#
?
Jan 29, 2016 11:38
|
|
|
abraham linksys posted:I should probably sit down and figure out redux-saga but every time I try to read an explanation like this my eyes glaze over and I retreat back to redux-thunk which is more than enough for my basic HTTP request needs. Thanks, I don't think we NEED saga per se, but the app could get pretty complicated so it may come in handy if everybody can get up to speed with it.
|
|
#
?
Jan 29, 2016 18:19
|
|
|
The ejohn tutorial (http://ejohn.org/apps/learn/) is a very, very good primer to all of the weird crazy poo poo that javascript is capable of, and everyone should do it, but it's also important that you don't try to incorporate everything in there into your production code just because you know it exists -- javascript is a super error prone language and the more complicated you make your code with things like .call()'s or javascript's hosed up version of oop, the more likely you or someone you work with is going to start prematurely balding.
|
|
#
?
Jan 30, 2016 04:05
|
|
|
Here's a dumb question. Are people using React and Redux in a non SPA situation? I've been thinking of going down that route because I'm not a huge fan of putting everything through React Router. I feel like I have to hard code the routes and it could get unwieldily as the application grows. It seems that React and Redux could be modular enough to be used across different pages.
|
|
#
?
Jan 30, 2016 07:31
|
|
|
Ochowie posted:Here's a dumb question. Are people using React and Redux in a non SPA situation? I'm not, but there's no reason you shouldn't be able to.
|
|
#
?
Jan 30, 2016 16:35
|
|
|
Ochowie posted:Here's a dumb question. Are people using React and Redux in a non SPA situation? Angular can be used in a similar fashion, you can think of it as each page having mini-applications in them. However, you lose a lot of the benefits of these frameworks, as you'll be unable to effectively share data between pages.
|
|
#
?
Jan 30, 2016 18:54
|
|
|
Ochowie posted:Here's a dumb question. Are people using React and Redux in a non SPA situation? I just finished a stint at <large company whose site averages around 13 million hits/day> and they use Angular as a non-SPA. In fact most of the modules on the page are individual angular apps. The way data gets shared is via dependency injection. It's....interesting. not sure it's a route I would have taken myself, however.
|
|
#
?
Jan 30, 2016 19:13
|
|
|
HaB posted:I just finished a stint at <large company whose site averages around 13 million hits/day> and they use Angular as a non-SPA. In fact most of the modules on the page are individual angular apps. The way data gets shared is via dependency injection. It's....interesting. not sure it's a route I would have taken myself, however. Can you elaborate on what you mean by that? It does sound interesting.
|
|
#
?
Jan 30, 2016 20:44
|
|
|
Ochowie posted:Here's a dumb question. Are people using React and Redux in a non SPA situation? I've been thinking of going down that route because I'm not a huge fan of putting everything through React Router. I feel like I have to hard code the routes and it could get unwieldily as the application grows. It seems that React and Redux could be modular enough to be used across different pages. You don't need to hardcode routes, at least not more than when you use server routing exclusively. And yes, enough people use them outside SPA applications. Search for universal or isomorphic to find a lot of examples which go a step further and do server rendering.
|
|
#
?
Jan 30, 2016 21:34
|
|
|
Perfectly Cromulent posted:You'll be just fine. Everyone has to start somewhere and it sounds like you are starting in a really excellent place. You were upfront about your lack of experience with the technologies they use, so there shouldn't be any surprises about it on their side. In some ways, that's a plus for them because it makes you malleable. I hired several people for mid-level development of an Angular app and I didn't give a poo poo if they knew Angular. I was more interested in them being sharp, communicating well, and knowing JavaScript. Frameworks come and go. My team was more than happy to teach them the ins and outs of the framework. Thanks for this, it's reassuring as hell and the guy interviewing me said the same thing about how I'll be learning good habits from the beginning due to my lack of experience. I've been using the resources posted here to get a glimpse into the technologies I listed but I definitely haven't been focusing on the fundamentals enough. Thanks for the links, I'll be putting more effort into learning everything I can about javascript and I've probably read more over the last week than the entire last semester of my degree. Can't wait to start the job now.
|
|
#
?
Jan 31, 2016 00:35
|
|
|
Skandranon posted:Can you elaborate on what you mean by that? It does sound interesting. The backend CMS is Drupal and it sets up a bunch of shared objects on the javascript side which can be injected into your angular apps. I never dug too deeply into the Drupal side of things, but you had to edit a Drupal.info file to get access to the injectors you used, depending on what you needed and how it got loaded. You also used the 'info file to pull in 3rd party js libs, or css as needed. It's an odd setup. Seems to be performant enough, but not so great to develop on (hence my leaving.) Drupal is now on my "never again" list, though I did have one other dev there tell me not to blame Drupal for the way they were using it, which is not really how most people use it. *shrug* All I know is - it seemed to be much more of a hindrance than a help to the developers, though I can see its value for non-technical content publishers. The other thing to be aware of in this particular case is that literally 95% of the data is one-way only, so every angular binding used ::. I'm sure the setup wouldn't work very well at all for something which was constantly manipulating data. edit: took out code example which wasn't really showing anything.
|
|
#
?
Jan 31, 2016 03:27
|
|
|
HaB posted:The backend CMS is Drupal and it sets up a bunch of shared objects on the javascript side which can be injected into your angular apps. Ah, I think I see, you were basically injecting information as Angular constants, which various services could pull in. I do something similar with configuration information before bootstrapping. Never used Drupal, and from the sounds of it, I never want to.
|
|
#
?
Jan 31, 2016 04:01
|
|
|
HaB posted:The backend CMS is Drupal and it sets up a bunch of shared objects on the javascript side which can be injected into your angular apps. I believe this was pioneered by weather.com, but the basic idea is that there is functionality that lets a user build dynamic page layouts in the user interface. Create a layout, add pre-built widgets into it such as content lists, slideshows, user activity, etc... The people that made weather.com took that idea and made it so that a front-end app would load as one of those widgets. There's a singleton of settings from the back end, and so this was probably injected into angular so it could make use of it. It worked for them, but it's not as optimized as it could be because it's still got JQuery and JQuery UI hanging around on all of the pages.
|
|
#
?
Jan 31, 2016 07:28
|
|
|
spacebard posted:I believe this was pioneered by weather.com, but the basic idea is that there is functionality that lets a user build dynamic page layouts in the user interface. Create a layout, add pre-built widgets into it such as content lists, slideshows, user activity, etc... The people that made weather.com took that idea and made it so that a front-end app would load as one of those widgets. There's a singleton of settings from the back end, and so this was probably injected into angular so it could make use of it. Ding! We have a winner! (There's no jQuery left I am aware of at this point.) Most of the discussion now is how to be less tightly coupled with Drupal, and whether or not the next version will use Angular or some other framework. Since there's so little two-way data flow, some people are of the opinion that Angular is overkill for that particular application. I was only there as a contractor for ~4 months and left because of Drupal. Great shop and great people otherwise.
|
|
#
?
Jan 31, 2016 15:12
|
|
|
spacebard posted:It worked for them For very generous definitions of "worked". I don't know how you build a site that spend 10-20 seconds as a broken mess while widgets pop in one-by-one and then decide that it's shippable.
|
|
#
?
Jan 31, 2016 17:35
|
|
|
It's not too hard to turn a regular website into an "SPA". If you're willing to be ghetto you can Ajax in entire HTML pages ala "turbolinks" (the Rails JavaScript library which implements this). Then you can share data between pages easier.
|
|
#
?
Jan 31, 2016 21:12
|
|
|
HaB posted:Since there's so little two-way data flow, some people are of the opinion that Angular is overkill for that particular application. This is a war being fought in a lot of large organizations right now. A handful of devs see Angular/React/whatever as the Golden Path, and want to write everything with it. These frameworks are yet more data clients need to download, the client needs to execute the JavaScript, page size is bloated with all sorts of decorators. When you're shooting for 1second load times, especially with mobile, you basically can't use any of these frameworks. On top of that, it seems silly to embrace two way data binding, or model -> view rendering on straight up web pages that aren't really stateful. Cool news - we're going live soon on our new front page and ditching React/jQuery/Babel and writing a tiny internal framework to handle the critical things. Not really relevant to this thread, but it's ASP.NET vNext deployed via Docker 
|
|
#
?
Feb 1, 2016 05:33
|
|
|
Helicity posted:This is a war being fought in a lot of large organizations right now. A handful of devs see Angular/React/whatever as the Golden Path, and want to write everything with it. These frameworks are yet more data clients need to download, the client needs to execute the JavaScript, page size is bloated with all sorts of decorators. When you're shooting for 1second load times, especially with mobile, you basically can't use any of these frameworks. On top of that, it seems silly to embrace two way data binding, or model -> view rendering on straight up web pages that aren't really stateful. Angular/React are much better for actual full blown web applications, not simple web applications. With web applications, you don't need to worry as much about initial page load, and can also reasonably expect the user to visit multiple times so the cache will eliminate most data transfer.
|
|
#
?
Feb 1, 2016 05:48
|
|
|
Helicity posted:When you're shooting for 1second load times, especially with mobile, you basically can't use any of these frameworks. I agree with much of what you said but if you're optimizing for load time, it's well-known in the React.js world to pre-render the page and send down the full HTML markup to the client. That gets you your 1 second load time. Once the client renders, it's essentially a no-op to the DOM because the actual DOM already matches the virtual DOM.
|
|
#
?
Feb 1, 2016 05:59
|
|
|
Where does Knockout feature in the landscape of all these frameworks?
|
|
#
?
Feb 1, 2016 12:31
|
|
|
Stoph posted:I agree with much of what you said but if you're optimizing for load time, it's well-known in the React.js world to pre-render the page and send down the full HTML markup to the client. That gets you your 1 second load time. Once the client renders, it's essentially a no-op to the DOM because the actual DOM already matches the virtual DOM. Let me rephrase real quick: You basically can't use any of these frameworks client-side if you're concerned about performance People are using it isomorphically - server side for rendering speed and SEO purposes, and then on the client to update content blocks as needed - because you get it for "free" and everything looks like a nail with the React hammer. A major downside of that, as I mentioned, is that you bloat your page with React's decorators. That bloat is not insignificant when sending large pages over the wire. Find a top 300 site out there using React and look at the flame charts for some of this stuff - it's not as small as you think, and all those 10ms here and there really add up. I don't think anyone here would argue against these frameworks making SPAs quite a bit easier to build, but there's a trap people (edit: not here) are falling into where they think performance critical pages with minimal state should use them as well, and that's just shooting yourself in the foot. Skandranon posted:With web applications, you don't need to worry as much about initial page load, and can also reasonably expect the user to visit multiple times so the cache will eliminate most data transfer. This is simply not true for sites that rely on traffic for revenue. Assuming all your assets are cached, you still have increased page download time from decorator bloat, extra time spent parsing/lexing the HTML, time parsing/evaluating the framework JS, not to mention actual render time. Again, take a look at your own web site's flame charts and you might be surprised how much performance you're leaving on the table. luchadornado fucked around with this message at 14:15 on Feb 1, 2016 |
|
#
?
Feb 1, 2016 14:01
|
|
|
I'm beginning to hit a pain point with my React project and am wondering if Flux is the solution. I'm still pretty unfamiliar with Flux, so my question here is basically "is this what Flux is meant to solve?" My issue is with the ever growing complexity of passing props down a long chain of components. And then sometimes I have a method in a child that needs to be called from its parent, which I know can be done but isn't recommended. So I begin second guessing my choice of which component should hold a particular state, but moving it will alter the way I call it elsewhere... and my head starts to hurt. Is Flux what I'm needing?
|
|
#
?
Feb 1, 2016 16:16
|
|
|
caiman posted:I'm beginning to hit a pain point with my React project and am wondering if Flux is the solution. I'm still pretty unfamiliar with Flux, so my question here is basically "is this what Flux is meant to solve?" My issue is with the ever growing complexity of passing props down a long chain of components. And then sometimes I have a method in a child that needs to be called from its parent, which I know can be done but isn't recommended. So I begin second guessing my choice of which component should hold a particular state, but moving it will alter the way I call it elsewhere... and my head starts to hurt. It definitely sounds like you need something to manage your state, and I've really enjoyed working with Redux. It's similar to Flux, but puts all state in a single store, which I find much easier to work with. EDIT: It looks like there's a series of tutorial videos by Redux's creator. I haven't watched them yet, but I've heard good things. Depressing Box fucked around with this message at 16:51 on Feb 1, 2016 |
|
#
?
Feb 1, 2016 16:45
|
|
|
|
| # ? May 8, 2024 06:09 |
|
|
Just to add some more fuel to the fire for client-side rendering with JavaScript: We are currently using a SaaS CRM, and for the past 2+ years we've had it, everyone's been complaining about how "slow" it is. Rarely has it actually been a network issue, maybe once or twice, but everyone still says it's slow. So, after many months of diagnosing here and there, it eventually led to me realizing something one morning. My  desktop at work always rendered pages quickly, but I never thought to compare this to an actual users rendering time within the browser. I went to an open seat one morning and played with a basic desktop, looked at the page renderings, and went  because it's all rendered on our side. Their desktops aren't as swanky, so of course the website is slow as poo poo for them as everything is rendered at runtime.
kloa fucked around with this message at 16:52 on Feb 1, 2016 |
|
#
?
Feb 1, 2016 16:49
|
|